Best practice when creating classes that are solely in charge of the creation of other objects i.e. factories?

Question

I often find myself creating classes that I suffix with 'Factory'. These classes tend to be solely in charge of the creation of a specific class or set of related classes. However I've always felt that this probably isn't best practice and that there's a better way of approaching this. One of the reasons that I believe that this isn't best practice is down to the fact that although I am using the 'factory' suffix I am not actually making use of the factory design pattern.

Let's say I have an class vehicle, that contains two variables make and model. I want my problem to be able to create a number of these vehicle objects, so I want to encapsulate the code to create these objects in a single class. I might create the below class.

public class VehicleFactory
{
    public Vehicle CreateVehicle(string make, string model)
    {
         //create vehicle..
         return vehicle;
    }
}

The VehicleFactory can then be used wherever I want in my program without repeating the code and violating DRY.

I often need to create these kind of factory classes when I'm refactoring code, more specifically when I find two or more classes that are creating the same objects. I'd want to refactor the code by pulling out the repeated code and then placing it inside a specific factory class.

Is there a better way to approach this issue?

Answer 1

Let us assume the logic inside CreateVehicle cannot be moved into the Vehicle constructor for some reason (like missing dependencies).

The issue you are facing is simply the ambiguous usage of the term "factory pattern", which is sometimes used for creating instances of different subclasses of a common interface, and sometimes just the way your questions shows it. For the latter, however, also the term "Builder" pattern is used, but that term is also to some degree ambiguous.

See also What is the difference between Builder Design pattern and Factory Design pattern?

Your approach is fine, don't overthink it. If you have doubts with the term "Factory", call such a class a "Builder" instead.

Answer 2

(Having java background)
This is actually not the use of the factory pattern. In your case, you simply just create a paramtrized object in another class. As long as the same instance is created, you just outsource the construction without any advantage. Your calling class is still depending on the factory class in a 1:1 relationship.

public class VehicleFactory
{
    public Vehicle CreateVehicle(string make, string model)
    {
         //create vehicle..
        if(model.equals("SUV")) {
            return new SUV(...);
        } ...

         return vehicle;
    }

}

public class SUV extends Vehicle {
            ....
}

If your method is creating objects of subclasses according to the passed parameters, this is where the factory pattern show its advantage. Only the factory is coupled to the subclasses, the caller isn't. He only knows that he has to call the factory and will get a vehicle. You don't need to import packages of vehicle subclasses.

Same applies, if you want to work with an interface. You can't generate the type of an interface, but a factory can create a concrete object implementing this interface and just return it as interface type. So again, you decouple dependencies and can just the objects interface to achieve your goals in the code.