Factories: Good and Not So Good Reasons to Use One

I remember the time when I first started to extensively used Factories in my code.
And boy is it embarrassing to even think about that code today. The only thing reducing the embarrassment somewhat is the fact that I see similar antipatterns in lots of code I’m not responsible for as well.

Lets go over some examples why you might want to use a Factory and what properties your Factory should have when used for that reason or maybe what other pattern you should consider.

In the context of this article a factory is any method creating new instances of some class.

Complicated Construction Sometimes creating an object of a class A is so complicated that I don’t want this construction logic inside the class A. The obvious choice is to create a Factory for creating A’s. This is one of the few cases where it is acceptable to make the factory method a static method or the Factory a singleton. But as we’ll see below there is a lot to be gained from Factory classes that themselve are normal Objects that can get created in a rather simple ways.

If you try separate the complicated creation process from the class it self you sometimes get the situation where you have a factory method which takes 5 or more arguments often some of these are optional, or you create half a dozen different Factory methods with different parameters. If this is the case consider a Builder instead. A Builder allows to add stuff piece wise.

Choose between a fixed set of different Implementations You might have different implementatios of interface A. A factory might choose the implementation or a client might use a factory to control the implementation to be used. An example are the Factory methods in the java.util.Collections class. When you are calling unmodifiableList you will get a very specific implementation. You are choosing that implementation by calling that specific method. You ain’t decoupling anything. Your client directly depends on that static method, which directly depends on that implementation. Maybe you are providing a nicer name or syntax for choosing the implementation, but thats about it.

Decoupling the implementation This is in my experience the most important use case for factories. It is also the one most often given as a reason for using a factory. Sadly in many cases the way the factory gets implemented completly fails to achieve this goal. In order to achieve the goal you have to inject the factory into its client, preferable through the constructor. Only if you do this you can switch the factory implementation and with the implementation of the Factory you can switch the implementation or configuration of the instance the factory returns. If you access the Factory through some static instance you completely loose that ability.

After shedding some light on valid use cases for Factories and the requirements they put on the Factories lets consider one especially popular way to fool yourself:

Passing Class Names
Sometimes you see APIs like public SomeInterface SomeFactory.createInstance(String className) in itself this API is fine. You are loading and instanciating classes by name. Its absolutely sensible to hide that in a neat little method, maybe you are doing some memoization inside. Nothing wrong with that.

But then a developer comes around and tells you this exists in order to decouple the client using that API from the implementing classes. This is when your bull shit detectors should go of. The client has to put the class name in a String. And a string with a class name is basically the same kind of dependency as a direct reference to that class. Actually it is worse, since no static code analysis will find it. So this is hiding a dependency not removing a dependency. Don’t ever mix that up. (I did it often enough in the past, no need for you to repeat that mistake).