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 https://github.com/joshnuss/design-patterns-in-elixir/blob/master/factory/run.exs

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


Pass in the actual module name… def process_order(module), do: module.process() and you are ready to go.


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 :blush:

1 Like

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.


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)

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: ...

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"

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)

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.

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

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…


Mind. Blown. I hadn’t even considered this approach (because I hadn’t really grok’d protocols until I thought about it in this light).

1 Like

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.

See above comment :wink:


Peter Norvig’s article about that.


This has some pitfalls.

  1. 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.
  2. 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…


Ehh, not really. The factory pattern is really a Java/C#'ism, not a static language thing. OCaml/Haskell/Etc… all approach it quite differently.


??? You mean the gof patterns are for oo (and indicate a smell).

1 Like

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.


This explicitness could even by a map in a config file for example for ease of changing later or downstream. :slight_smile:

1 Like

Good point, I could have been more explicit about statically typed languages with rather inexpressive type systems…


1 Like

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.

1 Like

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.

1 Like