Factory Pattern in Elixir?

fireproofsocks

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 5178 23

2019-02-13 20:04:27 UTC

Showing Posts 1 to 10

Show Best Posts
Show All (oldest first)
Show All (newest first)

NobbZ

No.

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

Post #1

PragTob

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

Post #2

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

asummers

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.

Post #4

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

fireproofsocks

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.

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

Post #6

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

fireproofsocks

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

Post #8

sribe

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