My understanding of a factory is that it encapsulates instantiation of concrete classes that all inherit a common abstract class or interface. This allows the client to be decoupled from the process of determining which concrete class to create, which in turn means you can add or remove concrete classes from your program without having to change the client s code. You might have to change the factory, but the factory is "purpose built" and really only has one reason to change--a concrete class has been added/removed.
I have built some classes that do in fact encapsulate object instantiation but for a different reason: the objects are hard to instantiate. For the moment, I m calling these classes "factories", but I m concerned that might be a misnomer and would confuse other programmers who might look at my code. My "factory" classes don t decide which concrete class to instantiate, they guarantee that a series of objects will be instantiated in the correct order and that the right classes will be passed into the right constructors when I call new()
.
For example, for an MVVM project I m working on, I wrote a class to ensure that my SetupView
gets instantiated properly. It looks something like this:
public class SetupViewFactory
{
public SetupView CreateView(DatabaseModel databaseModel, SettingsModel settingsModel, ViewUtilities viewUtilities)
{
var setupViewModel = new SetupViewModel(databaseModel, settingsModel, viewUtilities);
var setupView = new SetupView();
setupView.DataContext = setupViewModel;
return setupView;
}
}
Is it confusing to call this a "factory"? It doesn t decide among several possible concrete classes, and its return type is not an interface or abstract type, but it does encapsulate object instantiation.
If it s not a "factory", what is it?
Edit
A number of people have suggested that this is actually the Builder Pattern.
The definition of the Builder Pattern from dofactory is as follows:
Separate the construction of a complex object from its representation so that the same construction process can create different representations.
This seems like a little bit of a stretch also. The thing that bothers me is the "different representations". My purpose is not to abstract the process of building a View (not that that isn t a worthy goal). I m simply trying to put the logic for creating a specific view in one place, so that if any of the ingredients or the process for creating that view change, I only have to change this one class. The builder pattern really seems to be saying, "Let s create a general process for making Views, then you can follow that same basic process for any View you create." Nice, but that s just not what I m doing here.
Edit 2
I just found an interesting example in a Wikipedia article on Dependency Injection.
Under "Manually Injected Dependency", it contains the following class:
public class CarFactory {
public static Car buildCar() {
return new Car(new SimpleEngine());
}
}
This is almost exactly the usage I have (and, no, I did not write the wiki article :)).
Interestingly, this is the comment following this code:
In the code above, the factory takes responsibility for assembling the car, and injects the engine into the car. This frees the car from knowing about how to create an engine, though now the CarFactory has to know about the engine s construction. One could create an EngineFactory, but that merely creates dependencies among factories. So the problem remains, but has at least been shifted into factories, or builder objects. [my emphasis]
So, this tells me that at least I m not the only one who s thought of creating a class to help with injecting stuff into another class, and I m not the only one who attempted to name this class a factory.