I’m working on a problem that requires that a vendor-specific module be loaded to handle vendor-specific tasks related to an order. I’ve been trying out the behaviours, and that all makes sense. Coming from an OO background, however, I’m feeling the need to have a factory in this case… where I want to load up the proper module that implements the given interface, then call the do_something method on it. Conceptually, it’s pretty common OO.
However, in Elixir, the best I’ve come up with is either a big case statement or a series of declared functions that rely on pattern-matching in their signatures to send the execution flow to a specific vendor module, e.g. something like this:
What @NobbZ said, you could just call module.process() as then the function provides little extra value (I feel). Maybe call it vendor_module or something for more context
Using behaviour + @impl MyBehaviour above the callbacks will give the compiler the ability to help you if you get incorrect arity, or add an extra callback to the behaviour that your module doesn’t yet implement, for example.
Honestly, I don’t like the Factory pattern. I prefer to be a bit more data centric.
For example, each vendor has it’s own way to understand the orders, so you should have something like %VendorOneOrder{}, %VendorTwoOrder{}, etc… and they you apply the processing implementing a Protocol (ProcessableOrder). Then you implement all the declared functions of the protocol. For example:
defprotocol ProcessableOrder do
def from_order(to_order, internal_order)
def process(order)
end
And in each implementation, you do the following:
defimpl ProcessableOrder, for: VendorOneOrder do
def from_order(vendor_one, %Order{vendor: "vendor-one"}), do: ...
def process(order), do: ...
end
It will not solve the case problem, but at least you guarantee that the contract is kept in place if you add more Vendors. But it’s another approach to the same solution.
The responses here are far more interesting than I expected! Thanks!
Re passing the module name – to clarify, you are not passing a string representing the module name, right?
handle_processing(MyApp.VendorOne) # <--- can work with module.process() as desc'd above
# But the following won't work (?)
module_name = "MyApp.VendorOne"
handle_processing(module_name)
The problem, generally speaking, is that the logic that chooses which vendor (i.e. which module) to use must return a string because it is operating on database records and user input etc. So either I have a large case statement somewhere upstream that can specify the actual module names (not as strings), OR I have a large case statement and/or pattern matched functions somewhere downstream that establish the mapping between a string and an actual model name.
In other words, I can force the mapping upstream like this:
case choose_vendor() do:
"vendor-one" -> process_order(VendorOne)
"vendor-two" -> process_order(VendorTwo)
end
And then enjoy a cleaner downstream with def process_order(module), do: module.process()
Or, I have a cleaner upstream, e.g.
choose_vendor() |> process_order() # accepts a string
But then downstream I have to do pattern-matching or a case statement, e.g.
ALL of the “classic” (i.e. Gang of Four) patterns are specific to statically-typed languages, and virtually disappear with idiomatic use of dynamically-typed languages.
it will only work if the module name already exist! Either by preloading all modules or by having it already used in another already loaded module.
It relies on the (documented) implementation detail, that module names are actually built like this. Might break later on when we get private modules.
I tend to use Module.concat/1/2 and Module.safe_concat/1/2 here, depending on the level of trust I have in the data source, or an explicit whitelist, if I know all possible values in advance.
Yes. whenever you deal with some kind of stringified data you should verify it. In your case, you also need to convert it. This should happen as close as possible to the stringified data source. The same goes backwards, if you need to stringify it, do it as close to the data drain as possible. The remainder of your application should never have to deal with the stringified form, neither does it need to know it were strings somewhere else…
I definitely wouldn’t advise doing this, because it introduces a non-obvious coupling between the data in the database and the code. For example, if you refactor the code and don’t pay attention, the mapping is gone. Or even worse, some unwanted mapping might be introduced.
I would then convert the string to the alias (module name) immediately after the data is loaded. Similarly, I’d convert it back to string before it’s persisted. If you’re using Ecto, you can write a type for that.
This is exactly how I would go about doing things. I suppose that if you squint a bit this kinda looks like a factory from the OO world. But that comparison aside I think this is a very reasonable pattern for these sorts of scenarios.
I agree. The mechanics are inevitably somewhat different, but I think the idea is in its spirit similar: we’re consolidating a conditional and extracting it into a dedicated place. I think this is a useful pattern, even in an FP language.
The GoF patterns have nothing to do with static types. The GoF patterns were created based on work done primarily in Smalltalk, and to a lesser degree C++. Smalltalk is dynamically typed. Indeed, many of the patterns were about how to effectively make decisions using blocks (AKA functions) without static types or isMemberOf:/isKindOf: calls.
Smalltalk was also one of the big influences for Ruby, which in turn influenced Elixir.
