Imagine you have a baking machine, which can bake cookies. That machine allows you to provide a custom sprinkle application system as well as a custom system for cutting out the cookies into their final shape.

A behaviour would be used to document that the module you provide to the baking machine has a function (callback) for running the sprinkle application as needed, as well as the cookie cutting as needed.

You cannot check if a module actually implements a behaviour. The baking machine would just try to initialize e.g. the sprinkle application and fail if it’s missing. Often this is called ducktyping.

Now imagine an oven. An oven can bake many things, but those things all need to be properly prepared for baking. Muffin dough need to go in the muffin tray, a cake dough in a cake ring and the stew in a firesafe pot.

A protocol allows the baking logic to define “If something needs to get baked it needs to provide proper preparation instructions”. Then implementations for muffin, cake and stew can implement that protocol, so baking works without the baking logic needing to know how things are prepared in advance.

Protocol implementations can be checked when protocols were consolidated, but I’d argue you usually don’t want to do so as well.

Both are used for polymorphic code execution, but behaviours are around outer code receiving an implementation explicitly. Protocols are about polymorphism based on the type of data at hand.

You are on the right track thinking of behaviours and protocols combined as kind of like interfaces (or perhaps abstract classes). There is a separation in FP because behaviour and data aren’t combined. Behaviours define what functions can be called if we are passed a module; Protocols define what functions we can pass a struct without caring about its type (so long as it implements the protocol).

I’m not sure if this will be more confusing but another way to think about protocols, which you can see clearly in @adamu’s example, is they allow you to define a function implementation in one module that will be called by another another.

In practice I don’t think protocols are necessarily that useful in application code, though it very much depends on how you want to organize your code. As the guides call out, if you aren’t writing a library and aren’t concerned with extensibility, you have the option of keeping all the various implementations for different types (structs) in one module, ie, grouping by functions instead of data. The option to use protocols is certainly there, though!

A real world example I have is that I have some structs that can have an image associated with them that I want to store on S3. I want to be able to pass these structs to a function to convert them into an S3 path. Using a protocol you could define these in the structs’ modules themselves:

defprotocol Storage do
  def to_path(struct)
end

defmodule User do
  defstruct [:id, :name, :email]

  defimpl Storage do
    def to_path(%User{} = user) do
      "users/#{user.id}.jpg"
    end
  end

defmodule Product do
  defstruct [:id, :slug, :title]

  defimpl Storage do
    def to_path(%Product{} = product) do
      "products/#{product.slug}.jpg"
    end
  end
end

However, since I own all this code, I just define them in one module:

defmodule User do
  defstruct [:id, :name, :email]
end

defmodule Product do
  defstruct [:id, :slug, :title]
end

defmodule Storage do
  def to_path(%User{} = user) do
    "users/#{user.id}.jpg"
  end

  def to_path(%Product{} = product) do
    "products/#{product.slug}.jpg"
  end
end

Both these implementations result in identical callsites: Storage.to_path(user). I don’t particularly think one implementation is staggeringly better than the other. I personally find the non-protocol version simpler and I have all my S3 pathing stuff in one place, but there are arguments against it too. As always, YMMV.

As for behaviours, they are incredibly useful in application logic. They can be used for implementing the strategy pattern, for example.

Behavriours → interfaces in OOP with the difference that your function won’t pattern match on a behaviour but a module that has the callbacks defined in the behaviour.

e.g

defmodule A
  @callback do_a()
end

defmodule ImplementationOne
@behaviour A

def do_a(), do: "Implementation 1"

defmodule ImplementationTwo
@behaviour A

def do_a(), do: "Implementation 2"

What you would pattern match on would be ImplementationOne and ImplementationTwo instead of the behaviour

Protocols are about different implementations of a method depending on the type

So, if we have a protocol like:

defprotocol Size

def size(item)

When you implement the protocol for a string, the length function should return the number of characters in the string. But this implementation is not valid for a list. The implementation for the list should return the number of elements in the list. Likewise, this implementation is not valid for maps, for maps we want to return the number of keys in the map.

So, we have 1 method (size) and we have a different implementation based on he type (module)