Skip to content
Design Patterns

Abstract Factory


The purpose of the Abstract Factory pattern is to enable software developers to create families of related objects without exposing the specific classes to the client code. This promotes flexibility and interchangeability by allowing clients to work with different families of objects through a common interface.


The Abstract Factory pattern is applicable in scenarios where multiple families of related objects need to be created. It is particularly useful when the client code should remain independent of the concrete classes of objects being created, and when ensuring compatibility among objects within their respective families is essential.


The participants in the Abstract Factory pattern are:

  • AbstractFactory: An interface that declares methods for creating different types of objects within a family.

  • ConcreteFactory: Concrete implementations of the abstract factory interface, responsible for creating specific objects within a family.

  • AbstractProduct: An abstract base class or interface that declares common methods for the products created by the abstract factory.

  • ConcreteProduct: Concrete implementations of the abstract product, created by specific concrete factories, and belonging to a particular family of objects.

  • Client: The client code that uses the abstract factory to create objects within a family. The client should only interact with the abstract factory and abstract product interfaces, ensuring loose coupling with specific concrete classes.


The flow of the Abstract Factory pattern involves the following steps:

  1. Define the abstract factory interface (AbstractFactory) with methods for creating related objects.
  2. Implement concrete factory classes (ConcreteFactory) that provide specific implementations of the abstract factory interface, creating objects from different families.
  3. Create an abstract product interface (AbstractProduct) that declares the common methods that the products within the families should support.
  4. Develop concrete product classes (ConcreteProduct) that implement the abstract product interface. Each concrete product belongs to a particular family and is created by the corresponding concrete factory.
  5. The client code (Client) interacts with the abstract factory and abstract product interfaces only, creating objects from the desired family. This ensures that the client remains decoupled from the specific classes and can easily switch between different families of objects.

Real-world Scenarios

  1. GUI Libraries: AbstractFactory is used to create different sets of GUI components (buttons, text fields, menus) for various operating systems without changing client code.

  2. Database Abstraction: AbstractFactory helps create database-specific objects (connections, queries) transparently, allowing developers to switch databases seamlessly.

  3. OS Abstraction: AbstractFactory enables applications to work on multiple operating systems by providing platform-specific implementations for system calls and resources.

  4. Network Communication: AbstractFactory is used to create communication objects (sockets, protocols) that can be tailored for different network environments.

  5. Game Development: AbstractFactory allows creating various game elements (characters, weapons, power-ups) with interchangeable families for different game modes.

  6. Dependency Injection: AbstractFactory can be utilized in dependency injection frameworks to manage the creation of objects and their dependencies.

  7. Plugin Architecture: AbstractFactory facilitates the dynamic loading of plugins with different implementations while maintaining a common interface.

  8. Logging Library: AbstractFactory can be used to provide different logging backends (file, console, database) with the same logging interface.

  9. Localization: AbstractFactory supports the creation of localized resources (text, images) for different languages and regions in multilingual applications.

  10. Testing: AbstractFactory aids in creating mock objects and stubs during unit testing, improving testability and reducing dependencies on real implementations.


“Family Reunion”


“Family”: Represents the AbstractFactory, which creates families of related objects. “Reunion”: Denotes the gathering of ConcreteProducts, belonging to a specific family, created by the ConcreteFactory.

Imagine a “Family Reunion” where the AbstractFactory is the family head, responsible for organizing different family members (ConcreteProducts) from various branches (ConcreteFactories) to come together. Each member has their distinct role, but they all share a common family bond through the AbstractFactory. The gathering promotes flexibility and interchangeability, as members can switch places while maintaining compatibility within their respective families.