Abstract Factory
Intent
Produces families of related objects without specifying their concrete classes.
Problem
A UI kit needs buttons, checkboxes and menus that match: all Mac or all Windows, never mixed.
Solution
Declare an interface with one creation method per product; each concrete factory produces one consistent family.
Real-world analogy
A furniture shop sells matching sets: a Victorian chair, sofa and table, or a Modern set. You never get a Victorian chair with a Modern sofa.
Structure
Hover or tap a numbered role to highlight it in the diagram.
- 1ProductA — Abstract Products declare an interface for each distinct product of the family.
- 2ConcreteProductA1 — Concrete Products are variants grouped by family (A1 goes with B1).
- 3AbstractFactory — Abstract Factory declares one creation method per abstract product.
- 4ConcreteFactory1 — Concrete Factories each produce exactly one family of products.
- 5Client — Client only uses the abstract interfaces, so any factory or family can be plugged in.
Code example
Applicability
Use Abstract Factory when code must work with families of related products.
Use Abstract Factory when you want to enforce that products from one family are used together.
Pros and cons
Pros
- Products from a factory are guaranteed compatible
- Isolates concrete classes from client code
Cons
- Adding a new product kind changes every factory
Relations with other patterns
Check yourself
A game must create enemies, weapons and terrain that all match the selected world: ice, desert or jungle.
Saved in this browser only. Part of Creational patterns (0/5).