Creational

Abstract Factory

Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

Intent

Define an abstract interface for creating a suite of related products (a 'family') so that client code can work with any family interchangeably. The concrete factory determines which specific product variants are instantiated.

Problem

Your code needs to create sets of related objects — for example, UI controls that must all belong to the same visual theme, or data-access objects that must all target the same database engine. If you instantiate concrete classes directly, switching to a different family requires changes scattered across many files, and mixing products from different families introduces subtle bugs.

Solution

Declare abstract interfaces for each distinct product in the family, then declare an Abstract Factory interface with a creation method for each product. For every family variant, implement a concrete factory that returns products from that specific family. Client code works exclusively through the abstract interfaces, so swapping the entire family is a single-line change at the composition root.

Participants

AbstractFactory — declares creation methods for each abstract product in the family
ConcreteFactory — implements the creation methods to produce products of a specific variant/family
AbstractProduct — declares an interface for a type of product (e.g., Button, Checkbox)
ConcreteProduct — implements the abstract product interface for a specific variant (e.g., DarkButton, LightCheckbox)
Client — uses only the abstract factory and abstract product interfaces

Advantages

Guarantees that products from the same family are used together, preventing incompatible mixes
Isolates concrete product classes from client code (Dependency Inversion Principle)
Swapping an entire product family requires changing only the concrete factory (Open/Closed Principle)
Promotes consistency among products created by the same factory

Disadvantages

Adding a new product to the family requires changing every factory interface and all concrete implementations
Introduces many interfaces and classes, which can feel over-engineered for small families
Can obscure the code path — readers must trace through several layers of abstraction to see which product is actually created

Real-World Analogy

A furniture showroom is like an abstract factory. You choose a style — modern, Victorian, or Art Deco — and the showroom provides a matching set of chair, sofa, and coffee table in that style. You never mix a Victorian chair with a modern sofa because each showroom section (concrete factory) only produces items from its own style family.

Use Cases

UI toolkit that supports multiple themes (light/dark) or platform targets (Windows/macOS/Linux)
Database access layer that targets multiple engines (PostgreSQL, MySQL, SQLite) with compatible connection, command, and reader objects
Cross-platform document rendering that produces consistent PDF, HTML, or DOCX output families
Game asset loading that provides compatible sprite, sound, and animation sets per level theme
Cloud infrastructure abstraction that groups compatible compute, storage, and network resources per provider

Code Examples

abstract-factory.ts

// --- Abstract products ---
interface Button {
  render(): string;
}

interface Checkbox {
  render(): string;
  toggle(): void;
}

// --- Abstract factory ---
interface UIFactory {
  createButton(label: string): Button;
  createCheckbox(label: string): Checkbox;
}

// --- Dark family ---
class DarkButton implements Button {
  constructor(private label: string) {}
  render() { return `[Dark Button: ${this.label}]`; }
}

class DarkCheckbox implements Checkbox {
  private checked = false;
  constructor(private label: string) {}
  render() { return `[Dark Checkbox: ${this.label} ${this.checked ? "☑" : "☐"}]`; }
  toggle() { this.checked = !this.checked; }
}

class DarkThemeFactory implements UIFactory {
  createButton(label: string) { return new DarkButton(label); }
  createCheckbox(label: string) { return new DarkCheckbox(label); }
}

// --- Light family ---
class LightButton implements Button {
  constructor(private label: string) {}
  render() { return `(Light Button: ${this.label})`; }
}

class LightCheckbox implements Checkbox {
  private checked = false;
  constructor(private label: string) {}
  render() { return `(Light Checkbox: ${this.label} ${this.checked ? "☑" : "☐"})`; }
  toggle() { this.checked = !this.checked; }
}

class LightThemeFactory implements UIFactory {
  createButton(label: string) { return new LightButton(label); }
  createCheckbox(label: string) { return new LightCheckbox(label); }
}

// --- Client code works with abstract interfaces ---
function buildUI(factory: UIFactory) {
  const btn = factory.createButton("Submit");
  const chk = factory.createCheckbox("Remember me");
  chk.toggle();
  console.log(btn.render());  // theme-specific output
  console.log(chk.render());  // theme-specific output
}

// Switch theme by swapping the factory
buildUI(new DarkThemeFactory());
buildUI(new LightThemeFactory());

UI theme factory that produces consistent Button and Checkbox widgets for light and dark themes. Client code depends only on the abstract interfaces and can switch theme families at the composition root.

Related Patterns