1

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?

6
  • 2
    Usually, we call such methods "constructors". – Euphoric Jun 20 '19 at 9:57
  • @Euphoric Constructors would definitely be suitable for simple objects. The example was probably over simplified, but in more realistic terms these classes would be used for creating more complex objects, or lists of objects or something. Something that wouldn't be best placed inside a constructor. – Jake12342134 Jun 20 '19 at 9:59
  • @Euphoric: the usual problem such a factory solves is the "Vehicle" class hasn't access to all dependencies required for making a method like CreateVehicle work. – Doc Brown Jun 20 '19 at 10:00
  • Then provide concrete example of your full problem. Not oversimplification. So far, I see no reason to create a class just for this. – Euphoric Jun 20 '19 at 10:00
  • @DocBrown Yet, his example doesn't show this critical detail. – Euphoric Jun 20 '19 at 10:01
4

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.

2
  • But there is also a Builder pattern? – Jake12342134 Jun 20 '19 at 13:45
  • @Jake12342134: I recommend to read the top answer of the stack overflow answer I linked to, it has a detailed explanation. The borderline between what is sometimes called a builder or factory is sometimes blurry, but if you call the class for creation a factory or a builder is quite unimportant, use what fits best into your environment. – Doc Brown Jun 20 '19 at 14:23
0

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.