History of Behaviours?

[peerreynders]

@sztosz

Behaviours are similar to Interfaces in OOP language.

While this is an initially useful comparison it ultimately is a grossly oversimplified view.

OTP Design Principles: 1.2 Behaviours

Many of the workers are servers in a server-client relation, finite-state machines, or event handlers.

Behaviours are formalizations of these common patterns. The idea is to divide the code for a process in a generic part (a behaviour module) and a specific part (a callback module).

From the OO perspective behaviours need to be understood in terms of the intent of the Template Method pattern:

• Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure. (GoF)

i.e.

• Define the skeleton of a process, deferring some functionality to the callback module.

In Template Method the AbstractClass does expose an interface (implying a contract) that will be common to the ConcreteClasses but AbstractClass also contributes the common behaviour (which an interface cannot). In some ways the Template Method pattern is a compile time version of the Strategy pattern:

• Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. (GoF)

i.e.

• Define a family of processes (workers) which can be uniformly supervised and managed. Callback modules lets the process computation vary independently from how it is supervised and managed.

Similarly a behaviour module is in charge of most of the standardized (common) aspects of the process lifecycle while the callback module primarily deals with the specific computation (work) that the process is responsible for.

Behaviours are module based and are sometimes used at compile time to vary production and testing module implementations but that is a degenerate use case.

During runtime (process instantiation) a process composes the behaviour and callback module - i.e. it’s only through processes that a behaviour module can spawn “multiple instances” of the behaviour, each process manifesting a specific binding between a behaviour and a callback module with its own state.

---

@mmport80

Behaviours seem sorta unique in the FP world

Designing for Scalability with Erlang/OTP p.10:

OTP generic behaviors can be seen as formalizations of concurrent design patterns.

So from the OTP perspective behaviours are about processes, not FP.

---

See also:
Erlang Behaviors - …and how to behave around them (1/2)
Erlang Behaviors - …and how to behave around them (2/2)