From the "Gang of Four" design patterns, there's the Factory method:

class Factory(product)
  case product
  when a
    new A
  when b
    new B
  when c
    new C

new Factory(a)

Why is this more useful than having three classes, a, b, and c and calling them individually?

  • 1
    What do you mean precisely? Why not instantiate all three? Is that what you mean?
    – Neil
    Jun 6, 2013 at 7:57
  • 1
    @Neil No, in the factory pattern all the classes exist as siblings. Why call the factory to indirectly access the a,b,c classes?
    – alt
    Jun 6, 2013 at 7:58
  • 3
    this doesn't actually look like the factory method pattern to me, if anything its closer to abstract factory
    – jk.
    Jun 6, 2013 at 8:02
  • 2
    Because at design time you don't know which of the 3 classes you need to instantiate.
    – MrWhite
    Jun 6, 2013 at 8:02
  • 2
    @jk: No, it really doesn't. programmers.stackexchange.com/questions/81838/…
    – pdr
    Jun 6, 2013 at 10:28

7 Answers 7


Because your example is not complicated enough. For such a simple scenario it doesn't even make sense to use an advanced pattern.

But if you have to know more than the product to construct A, B or C, and you can't have direct access to that knowledge, then it is useful. Then you are using the factory to act as a knowledge center for producing needed objects.

Maybe those objects need a reference to some object X, which the factory can provide, but your code in the place where you want to construct A, B or C can't or shouldn't have access to X. Maybe when you have X you create A and B but if you have Y type then you create C.

Also consider that some objects might need 20 dependencies to create; what then? Going to hunt for those dependencies in a place where they should not be accessible might be problematic.

  • 16
    +1 for making it clear that Factory pattern is not always the best approach.
    – Neil
    Jun 6, 2013 at 8:33
  • 1
    Because your example is not complicated enough. For such a simple scenario it doesn't even make sense to use an advanced pattern. So what would you do in this case? Inline the conditional construction?
    – pdr
    Jun 6, 2013 at 10:31
  • It can be just method that takes product and returns what you need to make it reusable, so it doesn't have to be inline. If such method grows into something bigger, or is used in several other classes, you can refactor it to different class.
    – Mateusz
    Jun 6, 2013 at 11:34
  • The pattern is called Factory Method for a reason. The method doesn't have to be in a different class to be a Factory Method (though it often is).
    – pdr
    Jun 6, 2013 at 11:46
  • I've missed the "Method" in it, so you are right mister.
    – Mateusz
    Jun 6, 2013 at 11:54

The Factory Method pattern abstracts the decision-making process from the calling class. This has several advantages:

Reuse. If I want to instantiate in many places, I don't have to repeat my condition, so when I come to add a new class, I don't run the risk of missing one.

Unit-Testability. I can write 3 tests for the factory, to make sure it returns the correct types on the correct conditions, then my calling class only needs to be tested to see if it calls the factory and then the required methods on the returned class. It needs to know nothing about the implementation of the factory itself or the concrete classes.

Extensibility. When someone decides we need to add a new class D to this factory, none of the calling code, neither unit tests or implementation, ever needs to be told. We simply create a new class D and extend our factory method. This is the very definition of Open-Closed Principle.

You can even create a new factory class and make them hot-swappable, if the situation requires it -- for example, if you want to be able to switch class D on and off, while testing. I have run into this situation only once, but it was extremely useful.

As has been said, the Factory Pattern isn't always the way to go. But, wherever you see conditional instantiation, you should give it a moment's thought.

  • 1
    I always had difficulties grasping the whole benefits: specifically, allowing the open-closed principle - the calling code is closed for modification but the factory code is not - so the benefit lies in the factory code residing somewhere in the code base that will not require deploying to the client ? Can you exemplify ? Usually will not the factory code and business logic be part of the same dll ?
    – Veverke
    Jul 12, 2020 at 8:12
  • @Veverke I think what pdr means is that instead of having a whole bunch of if-else statements every time you need to choose between creating different classes, you might as well put all this logic into a factory. When you need to update the logic / support a new class, all you need to do now is to update the factory once. Compare to if you do not have a factory, every time you want to choose between creating different classes, you need to rewrite all the logic, and if you want to update the logic, you need to update the logic in every file which has it. Jul 23, 2020 at 4:54
  • @jarrettyeo: this is very confusing, and redundant - in my opinion. Introduce a whole new subject, make all that fuss around design patterns - to simply apply such a fundamental software engineering principle? (S from SOLID, DRY, etc) - one does need to face a problem in order to code avoiding code duplication - this is a guideline that should mostly always be applied.
    – Veverke
    Jul 23, 2020 at 11:12

A factory pattern is usually more complex than that. A factory decides on certain criteria which instance to create/return. Instead, when you don't use the factory, you would have that code repeatedly used in several locations in your code.

As an example consider the following: you need to load data from a DB, but you have one central DB for integration with lots of data, and one smaller one in memory on each dev-PC. In your code you ask a factory to get a DB-handle and the factory returns one of those depending on e.g. a configuration file.


The key advantages of the Factory pattern are twofold:

  1. The places that need an implementation of the product do not need to know how to construct one. The factory holds that information.

    Do you want to know what arguments to pass to the particular constructor? Or what dependencies you have to inject? Or how to register the implementation class with the database after it is fully configured? No? Let the factory look after all that stuff.

  2. The places that need an implementation of the product do not need to know at the time of module description (i.e., at compilation time) what the name of the implementation class is.

    Thus, a need not have anything to do with A; the “what to build” can be described in terms of the desired non-functional properties, and not just the name. This is much more flexible.

The downside is that where you know what to make and how to do it, you get more complexity when you use a factory. The fix to that is simple though: don't use a factory when it doesn't make sense!

  • So it is correct to say that this specific pattern helps as implement both S and O from SOLID principles ?
    – Veverke
    Jul 12, 2020 at 8:14

The Factory pattern is the most overused and abused design pattern.

I have come across numerous cases where a Factory class is coded when a simple constructor would be adequate.

Dont use a factory class unless:-

  • You depend on an external resource but you don't know exactly which one yet.
  • Construction is expensive and you want to build once and reuse many times.
  • Constructing a new instance depends on what instances have already been constructed (e.g. Your can only have five connections, or, you should use a connection id number one more than the last number used).

I would like to think about design patterns in terms of classes being as 'people,' and patterns are ways that people talk to each other.

So, to me the factory pattern is like a hiring agency. You've got someone that will need a variable number of workers. This person may know some info they need in the people they hire, but that's it.

So, when they need a new employee, they call the hiring agency and tell them what they need. Now, to actually hire someone, you need to know a lot of stuff - benefits, eligibility verification, etc. But the person hiring doesn't need to know any of this - the hiring agency handles all of that.

In the same way, using a Factory allows the consumer to create new objects without having to know the details of how they're created, or what their dependencies are - they only have to give the information they actually want.



Use Factory Method when instantiating a subclass and the client code isn't supposed to be responsible for deciding which particular subclass is instantiated.

It is useful because it prevents you from having to change client code when you need to change what class gets instantiated. Changing existing code is bad practice because it is typically error prone.

An example would be having subclasses, where each one sorts data in ascending order, but in a different way. Each way is optimal for a particular kind of data. e.g: partially sorted data, data that are numbers etc. The client code is a class that only handles printing of data. Having code that decides which sorting class gets instantiated in the client class would make it a complex class. In other words having more than one responsibility, in this case, deciding which sorting class is optimal and printing data. By putting the code that decides which sorting class gets instantiated into a Factory class it separates the concerns so that you don't need to change the client class every time you need to change which sorting subclass gets instantiated.

It's a way of covering your arse, if you can foresee your self-making changes down the line in how or what class gets instantiated then factory classes makes sense to use. It helps keep your classes focused on their one responsibility and as a result ensures that you are less likely to have to modify existing code that isn't related.

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