Want to have duck typing in Elixir?
{module, data} = value
new_value = module.some_function(value)
However if it is polymorphism you’re after, stick with protocols - even if you have to be explicit about implementing them.
peerreynders
fireproofsocks
The main drive in my thinking here is from having observed a large dev team bloat even simple applications into monolithic monstrosities. Maintaining as much modularity and separation as possible has been one effective way to help confine the bloat: keep services/apps as small as possible. In other words: if you can develop the functionality in one app in isolation and then use that component in a larger whole, that has generally equated to a win: faster dev/testing, and easier outsourcing and onboarding of devs. That is really the primary motivation in attempting to avoid the dependency on the “parent” OrderHandling being referenced as a @behaviour in the various vendor modules. Maybe attempting to obfuscate the relationship here is the wrong remedy to the problem.
Via dynamic dispatching, I can define a config value something like this:
config :my_app, :vendor_dispatch_mapping, %{
"vendor_one" => MyApp.VendorOne,
"vendor_two" => MyApp.VendorTwo,
}
And then in my OrderHandling module I do a dynamic dispatch like this:
def dispatch_vendor_processing(vendor_id, order_data) do
case Map.fetch(Application.get_env(:my_app, :vendor_dispatch_mapping), vendor_id) do
{:ok, vendor_module} -> vendor_module.process_order(order_data)
:error -> {:error, "Unmapped vendor"}
end
end
I’m trying to think through how protocols might work here when the OrderHandling and VendorOne modules may be in separate applications and the OrderHandling may not yet know the implementation details… I’m probably overthinking this.
0
OvermindDL1
That sounds all the more important to depend on OrderHandling! You need to keep the API’s the same so you know how to call them, and they can program to those API’s so they know when they work or don’t, especially with tests against the API. ^.^
1
opsb
When you use inheritance to share code you still have to state the child/parent dependency. The fact is there is a dependency. I’m not sure what is to be gained or even how it could be possible to hide this fact (in OO or functional). If you simply want to avoid the function call sites in VendorOne/VendorTwo knowing about where the shared function lives then you could use
defmodule AppOne.VendorOne do
import OrderHandling, only: [complex_function: 1]
def do_something(foo, bar) do
complex_function(foo)
end
end
1
LostKobrakai
If you want to keep dependencies small then extract OrderHandling in it’s own package and make your main application as well as VendorOne and VendorTwo depend on it. If you no longer need OrderHandling you can easily scrap it from all three packages. Also your vendors don’t depend on your main application but they can still be used together based on the behaviour of OrderHandling.
2