I'm learning about the Factory Method Desing Pattern and I'm having a hard time to understand exactly what it tries to solve and how.

Let's first introduce the example that Wikipedia uses to have a basis for the discussion.

enter image description here

So basically the products are MagicRoom and OrdinaryRoom, both derive from Room. And for the creators we have the base class/interface MazeGame which defines the method makeRoom, and the subclasses are MagicMazeGame and OrdinaryMazeGame. Now the client may either:

MazeGame game = new OrdinaryMazeGame()
MazeGame game = new MagicMazeGame()

Ok this is so we can talk about some example.

Now, Wikipedia describes the motivation as such:

to deal with the problem of creating objects without having to specify the exact class of the object that will be created.

And later on:

Creating an object often requires complex processes not appropriate to include within a composing object. The object's creation may lead to a significant duplication of code, may require information not accessible to the composing object, may not provide a sufficient level of abstraction, or may otherwise not be part of the composing object's concerns. The factory method design pattern handles these problems by defining a separate method for creating the objects, which subclasses can then override to specify the derived type of product that will be created.

Ok my assumptions are as follows: I'm writing code, and in my code I want to use the "products" - either a MagicRoom or an OrdinaryRoom. Now, instead of instantiating those in my client code, the Factory pattern says: don't do this! Rather, create another tree of classes which defines a createRoom method which will create the appropriate room. Now, instantiate this object and use createRoom. So I don't understand - if in my client code I don't want to "have to specify the exact class of the object that will be created" - how does this pattern helps me? I still need to specify which "creator" class I want to instantiate?

And as for the second quote about "require information not accessible to the composing object". I also don't understand - what kind of information will be in the creator class (e.g. OrdinaryMazeGame) which is not accessible in the client code?

The only thing I could think of being useful is if in my client code I have a lot of instantiations, and I want to be able to quickly change to another class, then instead of having a lot of room = new MagicRoom which I'll need to change to room = new OrdinaryRoom - I will have a single object with the makeRoom so I'll only need to change the type of this object from MagicMazeGame to OrdinaryMazeGame. Is this the core benefit of this design pattern?

It seems that all the examples out there about Factory Method pattern are so simple that the point of using just doesn't appear in these examples. Can someone give a good example

  • 1
    Your very last paragraph describes a problem I have with a lot of patterns. Commented Apr 3, 2022 at 7:02
  • 1
    The assumption is something like: you're writing a customizable library that other people can extend, and you have points in your logic where you need to instantiate objects of an unknown type (to be chosen, or even created, by the users of your library). The Factory method hierarchy can be separate from your core logic, but doesn't have to be. See my answer here for more details. Commented Apr 3, 2022 at 7:16
  • @FilipMilovanović, why isn't this assumption presented anywhere? Seems like it is a fundemental requirement...
    – YoavKlein
    Commented Apr 3, 2022 at 8:10
  • 4
    The primary source, the GoF book, actually opens with a "Motivation" section where they explain this. If you haven't come across this framing of the problem, it's because all of the online information represents secondary sources, and many authors either fail to express this clearly, or don't really understand the pattern itself. The maze example is actually from later on in the book, they use it to illustrate how to implement the pattern, but they don't lead with it. Commented Apr 3, 2022 at 8:26
  • 1
    @YoavKlein the pattern is potentially useful, even in a standalone application, as soon as you use interfaces or subclassing and have loose coupling between your app components. There are people using this pattern without even knowing it’s a pattern.
    – Christophe
    Commented Apr 3, 2022 at 9:34

2 Answers 2


The aim of the factory method is according to GoF:

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

The challenge in explaining the motivation is that the pattern has several flavors that address slightly different creational needs, depending on whether is is provided by an abstract class or a concrete class, and whether is is parameterized (i.e. the parameters of the factory method tell which Shape to instantiate) or not.

As you pointed out, the factory method can be a way to easily switch to antoher class being created, by isolating the creation in the method. But it also allows to select at runtime which class to create, by instantiating a different creator. Last but not least, the factory method also allows to inject a factory into other class that is unaware of what to create or how to chose the specific class to instantiate.

In Gof there are several pages to describe all these aspects. The main common idea is to decouple the creation of instances.


When you instantiate a class, you normally provide the class and some arguments. That will likely be repeated throughout your code.

When you use a factory, you don’t specify which class you instantiate at all. Best case, you give a description of what you use the instance for, and the factory will decide for you which class is instantiated to best support your use cases. If someone creates a new class, that class could be instantiated without any change in the caller. If you do unit testing, an instance of a mocked class could be returned. If you have different classes that are all compatible but optimised for different purposes, you might always get the best optimised one.

Yes, code to instantiate different classes will be there, in the factory method. But it’s there only once, and the author of the factory method will know best which class to instantiate. Much better than a random caller elsewhere.

  • Yes, code to instantiate different classes will be there, in the factory method - Well, you're right that the instantiation of products will be in the factory method, but the instantiation of the factory object will be in the caller, and that was my question.
    – YoavKlein
    Commented Apr 3, 2022 at 21:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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