Design Pattern: Factory Method

Recently I’ve been feeling the urge to study design patterns, memory and performance stuff in a more structured way. Here are my notes about the design pattern Factory Method. I’ll try to put it straightforward:

Factory Method

The description from Gang Of Four :

Define an interface for creating an object, but let sub-classes decide which class to instantiate. The Factory method lets a class defer instantiation it uses to sub-classes.

It looks like creating an abstract class as structure of objects, and then factory calls which objects to produce. It’s still not clear enough, what exactly does it mean?


Imagine that you are the factory manager and there are a list of products in the fruit factory. One day you want to request the factory for certain products, like “OK Factory, give me 2 organic strawberries and 2 California oranges”. Then the factory will produce and package these products for you in the next few hours.


You could simply call constructors:

And add them to your repository. It is OK but what if you need 1 million strawberries and 10 million oranges?

OR —

You could think this way, the products A, B, C… share some qualities (because they are all fruits) so they can be derived from the same class, let’s say PRODUCTS (so that fruits of sub-classes are polymorphous of PRODUCTS). Also, we want to keep it as simple as possible, where FACTORY could be something that encapsulates all these production details. Therefore in this way, the logic could be equivalent to:

You could also add a number to it:

Great! This is a step closer to the Factory Method describe in Solution One++.


Factory Method is basically the logic of FACTORY – produces – PRODUCTS. PRODUCTS are things that we are creating, FACTORY is the method to produce these PRODUCTS.

From what’s discussed earlier, we already have a plan in mind:

Now it’s very clear that what we need is the Products class and MyFactory.Produce() method.

On the PRODUCTS side, an abstract class or interface is needed to then create sub-classes as actual products. This is just Polymorphism.

On the FACTORY side, we need to create a Produce method to get the PRODUCTS.

WHY and WHEN to use Factory Method?

Compared to normal constructors, Factory Method is able to provide better encapsulation of the things to be created, and is clearer to the user about what and how many to instantiate. Constructors, however, are usually not explicit enough. Factory, as its name indicates, is something with all product information, no matter it is producing products or not, we can always turn to the Factory for what we need when we need it.

  1. Better encapsulation of product information
  2. More customization for instantiation, like quantities and colors…
  3. Better object-oriented concept, more explicit to users

HOW does it relate to game development?

Say we are making an garbage-collecting game, like Fallout, and there is a large inventory to manage. We would like to use certain tools when we need it, like knife, guns and bullets. Without having to remember what classes to instantiate, we would just need to create an Inventory as factory, call Inventory.Get(Tools tool) to acquire the things from the inventory. This is very useful especially if the inventory is very large with countless items.


Difference between Interface and Abstract Class —

Interface methods are implemented, they don’t have any implementation yet so there is nothing to override. While abstract class methods (which are default to virtual methods) are overridden. Usually abstract class can have some implementations and some abstract methods, it cannot be instantiated.

Leave a Reply

Your email address will not be published.