In my Java coding throughout the years, I have made extensive use of factories to produce desired objects. Of course, in recent years, the rise of dependency injection frameworks, particularly Spring, have eliminated the need for some of this. However, Spring does not really eliminate the factory; it simply becomes the factory itself. Furthermore, sometimes you need to perform some specialized object initialization beyond what Spring can support; then you need to either use a Spring factory method or a factory bean. And then you are back to a factory.
I was working on a C# project recently, and we were discussing my architecture. He was struck by my use of factory classes and told me that in the .NET world, developers simply do not create factory classes. Instead, they will create static methods or extension methods, such as a static Create() method on a domain object. He pointed out that this has the benefit of simplicity: the maintainer of the code only has to get their head around one class (the object created with the factory method) rather than two classes (an object and its factory). Also, you get the benefit of your code editor: a developer using your code does not even need to know about your factory method initially but will discover it via Intellisense.
These are certainly reasonable points, but of course, by using static factory methods, we lose the benefit of polymorphism. What if we want a class to be provided a factory so it can create objects, but the factory that it is provided could be one of several variants? For example, say I wanted a Worker class to create a IContentProvider according to some IContentProviderFactory that is injected into it. There could be multiple implementations of IContentProvider: FileContentProvider, DbContentProvider, etc. Static Create() methods on the FileContentProvider, DbContentProvider, etc. would force the Worker class to be aware of the various types of content providers rather than be agnostic of them.
In this case, if we are just producing one object dynamically at runtime, we could provide a delegate or lambda property or constructor parameter on our object. The method passed in could create the desired object and therefore serve as a factory.
However, if we have something more like an abstract factory pattern, in which we wish to have a factory that creates a series of related objects and you have more than one implementation of this factory, then this technique will not work very cleanly. In this case, we really DO need a factory class.
Any thoughts?
