fireproofsocks

Factory Pattern in Elixir?

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:

def process_order("vendor-one"), do: VendorOne.process()
def process_order("vendor-two"), do: VendorTwo.process()
def process_order("vendor-two"), do: VendorThree.process()

Or outlined more academically here design-patterns-in-elixir/factory/run.exs at master · joshnuss/design-patterns-in-elixir · GitHub

Is this idiomatic? Is there some other way to dynamically get a module name based on a parameter?

23 comments

#design #patterns

0 4642 23

2019-02-13 20:04:27 UTC

Marked As Solved

david_ex

FYI you could use the following to get module names from strings:

my_module = "MyApp.VendorOne"
module_atom = String.to_existing_atom("Elixir." <> my_module)
module_atom == MyApp.VendorOne
# true

Edit: as indicated by others below (e.g. @sasajuric’s), there are some better & safer approaches to this, so probably use one of those instead…

Post #7

Also Liked

imetallica

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.

Post #5

benwilson512

Author of Craft GraphQL APIs in Elixir with Absinthe

Relatedly, this fits in nicely if you can define a Behaviour https://elixir-lang.org/getting-started/typespecs-and-behaviours.html for the module that will do the processing.

Post #3

sasajuric

Author of Elixir In Action

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.

Instead, I’d make it explicit:

def vendor("vendor-one"), do: VendorOne
def vendor("vendor-two"), do: VendorTwo

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.

Post #14

Last Post!

OvermindDL1

Just referencing modern day and what people would know it from. I’ve used factories way back since before C was standardized so I know it is very old pattern. ^.^;

This is the big key!!

You can put the ‘hardcoded’ map in the config files, then in the app anytime you need it access it via Application.get_env/2 and query it directly. You can even do that at compile-time to build up function matchers but by keeping it at run-time you can allow for it to be changed while the system is running to add/remove things to it without needing a hot code swap or reload.

The configuration itself would just be a mapping of stringnames ↔ module names, or even full MFA’s if you want.

Protocols are for dispatching on a type like a struct type so if you have that then absolutely yes, otherwise the plugin model is better (which you can also do via any arbitrary tag, like a string, with my ProtocolEx library ^.^).

Post #23