Is it confusing to call this class a "factory"?

Question

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.

Answer 1

This doesn't sound much different to me than a constructor for an instance of SetupView. Perhaps too much code context has been elided from your example, but I don't see why what you have right there couldn't simply be written as a constructor, and the arguments passed as args to the constructor.

Judging strictly from GoF patterns, I think it misses the mark on Factory for two reasons:

1. there is no family of related/dependent objects
2. the concrete class is, indeed, specified

With regard to Builder, I think it misses in the aspect of variance of products.

When I teach Design Patterns courses, I tell students to look not just at the intent of a pattern when trying to determine "best fit", but rather look at applicability and structure/participants. The intent can help you rule things out, but applicability & structure/participants are what will help you home in.

If you can identify what part of your design fulfills the various roles of the participants in either (Abstract) Factory or Builder, then you've made a good case for using that nomenclature.

Answer 2

It looks to me like what you have there is more of a Builder pattern than a Factory pattern.