Home Articles

Factory Method Pattern

Let us discuss how factory design pattern in this article:

Factory Design Pattern


A factory is an industrial site, usually consisting of buildings and machinery, where workers manufacture goods or operate machines processing one product into another.

Different goods type has a different requirement for manufacture, like cloth factory raw materials are fabrics, trims [sewing thread] and accessories [buttons, zippers, decorators, etc].

At a broad level, You need to give raw input to a factory, it processes and returns your desired product. Sometimes a factory may need to delegate some processes to other factories.

For some factories or industries, the quality check comes in a category. Imagine you are manufacturing smartphones, for that you need electronic components from your supplier. You are buying gold or rubber tires where composition influences the value and performance of the product. Would you like to buy a 24-karat gold ring only to discover later that it’s only 10 karats?

Most importers don’t rely on the factory to conduct materials verification because tests often require specialized equipment and the factory may lack in doing this.

Letting staff at the factory perform the IQC [Internal quality control] testing also presents a conflict of interests. Factory staff is vulnerable to meet standards.

Outsourcing the validation at the factory gives more focused work to the factory. Component and materials testing methods will vary based on your product type. But regardless of product type, relevant lab testing will help you verify whether raw materials and components meet your requirements for the product’s intended requirement.

#Factory Method:


It’s a creational pattern that is used when choice has to be made among classes that conform to common factory protocol. This pattern allows implementation classes to create objects by hiding implementation details from component which is going to consume object.

What are the benefits?

This pattern consolidates the logic that decides which implementation class is selected and prevents it from being duplicated throughout the application. It means that calling components rely only on the top-level protocol and do not need any knowledge about the implementation classes or the process by which they are selected.

When should you use this pattern?

  1. Use this pattern when you have several classes that implement a common protocol or that are derived from the same base class.
  2. a class can’t anticipate the class of objects it must create.
  3. classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate.

When should you avoid this pattern?

Do not use this pattern when there is no common protocol

Pattern correct implementation check:

This pattern is implemented correctly when the appropriate class is instantiated without the calling component knowing which class was used.

Any related patterns:

This pattern is often used with singleton or object pool patterns.


We have to design a travel system where we have to draw layout based on travel type requested by the client. Travel type could be Bus, Train, Flight or Bla Bla Car.


A Client just cares about layout, it doesn’t mind about who is implementing.

We could have a factory class to provide layout based on travel type.

Example 1

Example 2

In the future, if you get a requirement to add a new travel type, you could easily create a layout of that new type by conforming from TravelLayout without client knowing about implementation details. In this example, we create a layout by checking travel type.

Delegating Decisions for Deeper Class Hierarchies OR Dealing with complex logic to choose implementation class

If you are dealing with a deep hierarchy of implementation classes, then it can be useful to delegate some of the decision logic into the classes themselves OR you might need to write complex decision logic repetitively at multiple places to decide implementation class. It’s better to move logic to the implementation class and let it decide what to return.

Patterns that could be used with this Pattern:

Here I have used a singleton pattern to get travel layouts from the factory. You might have multiple functions to call from the factory in that case you create object of factory and call functions using object instance. In that case, instead of creating layout objects each time, you could utilize the object pool pattern to the fullest. Composition can also be used with this pattern.

This is a free third party commenting service we are using for you, which needs you to sign in to post a comment, but the good bit is you can stay anonymous while commenting.