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