OOP like handler inheritance

I have been doing functional for a while already, but there’s some OOP pattern that I still like and can’t find the right approach to it

This pattern is a hierarchy of objects, a set of handlers (per object type) and a factory to instantiate the right handler based on caracteristics of the object.

I was wondering if someone has a nice and elegant implementation of this whole thing (behaviors with something else maybe?). I guess with pattern matching it can be cool

Some OOP example

Msg1 extends Msg extends Dao
Msg2 extends Msg extends Dao

Abstract MsgDispatcher
Abstract send(Msg m)

DispatcherOne extend MsgDispatcher
send(Msg m): ...

DispatcherTwo extend MsgDispatcher
send(Msg m): ...

Factory.getDispatcher(Msg1).send(Msg1) will invoke the method in DispatcherOne

Thanks!

No inheritance, rather composition.

That’s a good fit for Protocol.

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

2 Likes

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.

2 Likes

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