Abstract Factory Pattern
The Abstract Factory pattern is a creational design pattern that provides an interface for creating families of related or dependent objects without specifying their concrete classes, allowing a client to remain agnostic about which…
Definition
The Abstract Factory pattern is a creational design pattern that provides an interface for creating families of related or dependent objects without specifying their concrete classes, allowing a client to remain agnostic about which specific implementation family it is working with.
Overview
The Abstract Factory pattern is one of the Gang of Four's five creational patterns, and is often described as a 'factory of factories.' Rather than instantiating concrete classes directly, client code depends only on abstract factory and product interfaces; a concrete factory implementation is responsible for producing a complete, mutually compatible family of concrete product objects. Swapping which concrete factory is used swaps the entire family of related objects the client receives, without any changes to the client's own logic. A canonical example is cross-platform UI toolkits: an abstract `GUIFactory` interface might declare `createButton()` and `createCheckbox()` methods. A `WindowsFactory` implementation returns Windows-styled button and checkbox objects, while a `MacFactory` implementation returns Mac-styled equivalents. Client code written against the abstract `GUIFactory` and abstract `Button`/`Checkbox` interfaces can render a consistent UI regardless of which concrete factory was configured at startup, and the pattern guarantees that a Windows button is never mixed with a Mac checkbox, since both come from the same concrete factory. Abstract Factory is closely related to, and often built using, the simpler Factory Method pattern — each creation method on a concrete factory is frequently implemented internally as a factory method. It differs from Factory Method in scope: Factory Method concerns creating a single product, while Abstract Factory concerns creating an entire family of related products that must work together consistently. The pattern's main cost is added complexity and indirection: introducing a new product to the family typically requires updating the abstract factory interface and every concrete factory implementation, which can be a significant change if there are many concrete factories. It is most valuable when a system needs to support multiple interchangeable families of related objects and must guarantee internal consistency within whichever family is selected.
Key Concepts
- Creates families of related objects without exposing concrete classes to the client
- Guarantees that objects from the same family are used together consistently
- Client code depends only on abstract factory and product interfaces
- Swapping the concrete factory swaps the entire product family at once
- Often implemented internally using multiple Factory Method implementations
- Adding a new product typically requires updating every concrete factory
- One of the original 23 Gang of Four design patterns
- Commonly used for cross-platform or theme-based object families