Jens Schauder is software developer since 1997. He loves software development for the constant challenges and constantly changing environment. A great chance to learn and teach. He is also blogger, author of various articles and speaker at conferences. Jens is a DZone MVB and is not an employee of DZone and has posted 81 posts at DZone. You can read more from them at their website. View Full User Profile

Factories: Good and Not So Good Reasons to Use One

09.13.2012
| 7500 views |
  • submit to reddit

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

Published at DZone with permission of Jens Schauder, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Yaozong Zhu replied on Fri, 2012/09/14 - 5:08am

Nice article, Jens.

 

In general, I think Dependency Injection does make less and less use case for Factory pattern. With the rich DI APIs available, even the use case of choosing from different implementations sometimes doesn't require Factory.

Johan Sjöberg replied on Fri, 2012/09/14 - 2:07pm in response to: Yaozong Zhu

I agree, good article, and yet again, I agree on the DI note. Two primary ways I use instance factories with DI are

  1. I need to get multiple instances of the same class.
  2. When using the abstract factory pattern to only depend on an API while letting implementations provide a concrete factory for producing complex objects. 

One of the (very few) decent uses for static factories though (in my opinion) is naming construction logic. E.g.,

Lists.newArrayList();
Lists.newLinkedList(); 

 

Allen Chee replied on Thu, 2012/10/11 - 9:11pm

Good article. In fact I have refactored a project's extensive use of custom factory classes to POJOs having its dependencies wired up via Spring. What most of the custom factory classes do is to read properties file values just for the caller to 'easily' write a 1-liner Factory.getInstance() statement to get the desired object. But this is just shifting the complexity elsewhere. However as you've pointed out, if there's a fixed set of different implementations then using Factories is viable.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.