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

2019-02-13 20:04:27 UTC

Showing Posts 23 to 14

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

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

asummers

Protocols are what you’re looking for, I think. Elixir doesn’t know about all the enumerable data structures, but it defines a protocol that allows extension of your data structure to become enumerable, by doing

defimpl Enumerable, for: MyModule do
  # enum protocol implementation
end

Similarly if your code defines a behaviour, and the library has a function that knows how to dispatch to the appropriate behaviour callbacks, you can simply pass your module into the dispatcher and it can execute the relevant callbacks, having faith that they’ll be there.

Post #22

fireproofsocks

Could you elaborate on that? One of the things I’m stuck on here is how I might have a package (say, something that gets published on Hex), and then how could I build it in a way that would open up customizations to users without requiring them to edit my code (which would be a big no-no)?

E.g. if I build out the mapping internally that handles the mapping of “condition-one” to SomePrivateModule.do_something() and “condition-two” to SomeOtherPrivateModule.do_something(), how could that mapping be extended via configuration so that a user could supply their own mapping so that “condition-three” maps to UserDefinedModule.do_something() ?

Thanks!

Post #21

roblally

Neither Java nor C# existed when the GoF patterns were written down. It should also be noted that the GoF patterns book does not contain a Factory pattern. It contains two patterns that have the word Factory in them and two more that are factories in the modern sense but don’t contain the work Factory.

AbstractFactory
FactoryMethod
Builder
Prototype

Not all patterns are useful in all contexts, and you’re 100% right that different languages have different idioms and different needs.

Post #20

roblally

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.

Post #19

sasajuric

Author of Elixir In Action

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.

Post #18

keathley

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.

Post #17

sribe

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

Yes.

Post #16

OvermindDL1

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

Post #15

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

Load more posts (13 remaining)