OOP like handler inheritance

No inheritance, rather composition.

That’s a good fit for Protocol.

Pattern matching? Multi clause functions should do the job, maybe.

the official way to do this is with behaviours protocols, and a liberal use of defdelegate.

If you don’t want to do it with protocols directly, you can also use a protocol-lite:

defmodule Api do
  @callback foo(struct) :: integer
  @callback bar(struct) :: integer 
end

defmodule Msg1 do 
  defstruct [... fields ...]

  @behaviour Api

  def foo(struct), do: ...
  def bar(struct), do: ...
end

defmodule Msg2 do
  # demonstrates oop-style multiple-dispatch
  defstruct [... fields ...]

  @behaviour Api

  def foo(struct), do: ...
  def bar(struct), do: ...
end

defmodule Msg3 do
  # demonstrates OOP-style inheritance
  defstruct [... fields ...]
  
  @behaviour Api

  # note that the fields in Msg3 type must be compatible with the Msg1 and Msg2
  # function expectations of the field parameters, or else you will have a bad time.
  defdelegate foo(struct), to: Msg1
  defdelegate bar(struct), to: Msg2
end

defmodule Action do
  def adds_foo_and_bar(msg = %msg_type{}) do
    msg_type.foo(msg) + msg_type.bar(msg)
  end
end

# these statements dispatch against their respective module's foo and bar statements
Action.adds_foo_and_bar(%Msg1{...})
Action.adds_foo_and_bar(%Msg2{...})
Action.adds_foo_and_bar(%Msg3{...})

Note that making sure that the structs have compatible fields you need is your responsibility, if you want you can probably whip up some compile time macros to check that the structs are compliant**. And the “inheritance” of your functional components is also very much explicit, there’s no “inherit” that makes your code consumer guess what gets inherited and what doesn’t.

** hints: A module with defstruct implements the __struct__/0 function and at compile time you can retrieve the module’s struct-being built with Module.get_attribute(__MODULE__, :struct)

Anyways this kind of stuff is a little bit on the hard side because maybe this sort of abstraction is not necessarily the best thing to do. I’m still not sure if it’s a good pattern from OOP or an antipattern.

Everything you showed is achievable in many FP languages. You’ll have to specify what you cannot do in particular because I don’t see such a thing.

Thanks this is actually even too much OOP :smiley

I am not sure, I think I look for an elegant way to maintain the factory, like in a little programatic dependency injection