# Passing functions between processes

**URL:** <https://forum.elixirforum.com/t/passing-functions-between-processes/27090>\
**Category:** Questions\
**Tags:** troubleshooting\
**Created:** [November 24, 2019, 11:47pm UTC](https://forum.elixirforum.com/t/passing-functions-between-processes/27090 "2019-11-24T23:47:57Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![peerreynders](https://forum.elixirforum.com/user_avatar/forum.elixirforum.com/peerreynders/32/5826_2.png) [@peerreynders](https://forum.elixirforum.com/u/peerreynders)\
**Post date:** [November 25, 2019, 3:17pm UTC](https://forum.elixirforum.com/t/passing-functions-between-processes/27090/5 "2019-11-25T15:17:14Z")

</div>

Welcome to the forum!

> [@Smool](#):
>
> 1. pass the function as an init arg to the component

> [@al2o3cr](#):
>
> Behaviors specify `@callback` functions that any module that uses the behavior needs to define. You’ll frequently see those implementations annotated with `@impl true` or `@impl WhateverTheBehaviorModuleIs` .
> 
> `GenServer` and `Plug` are both good examples of this style.

That ceremony could overcomplicate things at least initially as I suspect that there already is a `GenServer` _callback module_ implementation that does most of the work:

> I’ve got a pretty generic GenServer that I’ve created that I want to use in a few contexts.

What it sounds like is that the `GenServer` _callback module_ in itself needs further specialization by being bound on _yet another separate_ callback module - within this discussion the _strategy callback module_.

So really the essence here is that a _callback module_ is simply the name of a module that promises to implement certain functions that the _behaviour module_ will invoke on it.

The name of the _strategy callback module_ can be passed as one of the arguments to the [`init/1`](https://hexdocs.pm/elixir/GenServer.html#c:init/1) callback and stored in the `GenServer` state, e.g.:

```elixir
  def init(args) do
    with {:ok, strategy} <- Keyword.fetch(args, :strategy) do
      {:ok, %{strategy: strategy}}
    else
      _ ->
        {:stop, :badarg}
    end
  end

```

Then later the function can be called as (provided the `GenServer` state is bound to `state`):

```elixir
result = state.strategy.the_fun(the_arg)

```

or

```elixir
result = apply(state.strategy, :the_fun, [the_arg])

```

[`Kernel.apply/2`](https://hexdocs.pm/elixir/Kernel.html#apply/2)

At the simplest level I would compare behaviours to the strategy pattern though there are also elements of the template method pattern.

> [@History of Behaviours?](https://forum.elixirforum.com/t/history-of-behaviours/19588/10):
>
> While this is an initially useful comparison it ultimately is a grossly oversimplified view. [OTP Design Principles: 1.2 Behaviours](http://erlang.org/doc/design_principles/des_princ.html#behaviours) 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,…

> [@Behaviours & Protocols](https://forum.elixirforum.com/t/behaviours-protocols/17245/3):
>
> I see the intent behind either as being quite different. However historically OO has often conflated the notion of polymorphism and implementation inheritance - so it would be very easy to fall into the same trap. Protocols are ultimately about polymorphism. One part is the interface that will give access to the same polymorphic behaviour. Then each data type wishing to expose that behaviour implements it separately. Behaviours are about separating the generic implementation from the specific.…

> [@Behaviours in Javascript?](https://forum.elixirforum.com/t/behaviours-in-javascript/22668/4):
>
> Behaviours use a conceptual contract between the (generic) behaviour module and the (specialized) callback module - but that doesn’t mean a behaviour is-like an interface - because that doesn’t look at the whole picture. Is the strategy pattern like an interface? No, the Strategy implements the interface that the Context accepts. For some more details see [here](https://forum.elixirforum.com/t/history-of-behaviours/19588/10). So in JavaScript you would use the Strategy Pattern Context → Behaviour Module Strategy → Callback Module The Context is the gener…

---

_[View the full topic](https://forum.elixirforum.com/t/passing-functions-between-processes/27090)._