Skip to content

Creational Design Pattern: Abstract Factory Pattern

Abstract Factory pattern is an extension of Factory pattern where even the factory is abstracted out. In factory pattern you just Abstract out on the type of object you want to create thus by creating a factory that can provide a similar object set like in our example the Animals in Animal’s kingdom. But what if we need to create multiple objects that our in different subsets. For example, in Animal’s kingdom there are not just animals that can roam, what about Birds, Reptiles or Water Animals? They all cannot be a part of animal set which only implements roam method.

This pattern is all about making our design more flexible so that we can change any component without modifying other classes that depend on that component. So we have Abstraction layer for factory and Abstraction layer for Objects.


First let’s define our Abstract objects, say we have two type of objects one of “BaseOne” type and other of “BaseTwo” type.

Abstract Factory Pattern UML diagram
Abstract Factory Pattern UML diagram

Lets see some code based on the above class diagram.

Now, Lets first define our Abstract Factory class. Any factory that extend this factory type will create objects of two types that are defined above.

Each Abstract base class can have multiple objects, we have two of each types. Each object will give concrete definitions to the behaviors declared by the Base classes, their logic will be encapsulated from the client side.
Any Client will never depend on these implementations which will give us the flexibility to change the logic at any time without changing the client code.

Now we need concrete factory classes that will actually implement the Abstract Factory to provide concrete objects to the client. The client will never depend on the logic these factory method uses to create the object as long as they have the object of the type they need either BaseOne or BaseTwo.

Finally we need one factory builder to give us the correct factory we need and how it will be used in client side.

This sum ups how abstract factory method pattern is defined.

Practical Example

The code may not make sense at first as it’s quite big and complicated so let’s try to come up with a practical example that will define the pattern in a more general use case. Assume we are going to implement an Application that is going to support multiple themes. This is a very general problem that shows the best use case of Abstract Factory method pattern.

Go through the code to understand it correctly.

With the above example we can conclude few points:

  1. Adding a new theme will not result in modification in client code or any other code that actually implements other themes.
  2. Each theme and button behavior is not related to any other classes.
  3. All classes are very loosely coupled.
  4. Modifying any existing theme won’t result in modification in any other theme or client side code.
  5. Themes are open for extension but closed for modifications.
  6. This pattern makes sure to inverse any dependency there by making code more flexible.

Advantages of Factory Pattern

  1. Reuse: When we want to instantiate a new object we don’t need to repeat the if-else conditions. We just call the Factory method.
  2. Unit-testability: When we are writing unit test for the application we just write few unit tests to test the factory method and once its pass then we never test the object creation in the test suits. We just test caller and its return values.
  3. Extensibility – Whenever in the future we want to add a new class to the factory we don’t need to change the client and unit test already written for the pre-existing code. We just go ahead and add the new class to the source and update the factory method and its unit test.
  4. Adds two Abstraction layer to keep client and Object creation separate making loosely coupled class structure.

Disadvantages of Factory Pattern

  1. This is one of the common disadvantage in almost all of the design pattern. You need to write quite a lot of boiler plate code.
  2. If there are too many child classes, if-else ladder or switch statements quite large to keep them in check.
  3. Adds quite a lot of boiler plate code.

This is it for the Abstract Factory Pattern.
As always Thank you for reading.

Published inDesign Patterns

Be First to Comment

    Leave a Reply

    Your email address will not be published. Required fields are marked *