Abstract Factory

The four moving parts

Abstract Factory has four roles. They look like a lot at first, but each one is small, and together they lock in the 'always matching' guarantee:

• Abstract products — one interface per kind of thing in the family: Button, Checkbox, Card. These say what a button can do, not what it looks like.
• Concrete products — the real theme versions: LightButton, DarkButton, LightCard, DarkCard, and so on. Each one implements its abstract product.
• The abstract factory — one interface, ThemeFactory, with a create method per product: createButton(), createCheckbox(), createCard().
• Concrete factories — LightThemeFactory, DarkThemeFactory, OceanThemeFactory. Each one builds its own matching set of concrete products, and nothing else.

interface Button   { render(): string; }
interface Checkbox { render(): string; }
interface Card     { render(): string; }

// One factory interface for the whole family.
interface ThemeFactory {
  createButton(): Button;
  createCheckbox(): Checkbox;
  createCard(): Card;
}

// A concrete factory builds ONLY its theme's matching set.
class DarkThemeFactory implements ThemeFactory {
  createButton()   { return new DarkButton(); }
  createCheckbox() { return new DarkCheckbox(); }
  createCard()     { return new DarkCard(); }
}

Notice that DarkThemeFactory can only make dark parts. There is no method on it that returns a light card. That's the whole trick: because a single factory builds the entire family, the family can't be mixed. Consistency isn't something the developer has to remember — it's built into the structure.

The client stays theme-agnostic

The best part is the code that uses the widgets. It receives some ThemeFactory and never asks which one. It just calls createButton(), createCheckbox(), createCard() and lays them out. It has no idea whether it's building a light UI or a dark one — and it doesn't care:

function buildUI(factory: ThemeFactory) {
  const button   = factory.createButton();
  const checkbox = factory.createCheckbox();
  const card     = factory.createCard();
  // The client never mentions Light or Dark — it just wires them up.
  return [button.render(), checkbox.render(), card.render()];
}

buildUI(new DarkThemeFactory());   // a fully dark UI
buildUI(new LightThemeFactory());  // the same code, a fully light UI

Adding a new theme is cheap

Want an Ocean theme? Write OceanButton, OceanCheckbox, OceanCard, and one new OceanThemeFactory that builds them. You add code without touching any existing factory or the client. That's the Open/Closed Principle in action: open for extension (new themes), closed for modification (nothing old changes). The catch to know: adding a new kind of product — say every theme now needs a Slider too — means editing the ThemeFactory interface and every concrete factory. Families are easy to add; new family members are not.

Use Abstract Factory when several things must be created together and match

Reach for it whenever your program needs to build a set of related objects that only make sense as a matched group, and you may want to swap the whole set for another:

• Cross-platform UI toolkits — a Windows widget set (Windows button, Windows scrollbar, Windows menu) versus a macOS set. One factory per platform hands your app a whole native-looking family.
• Swappable database drivers — a connection, a command, and a reader that must all come from the same driver. A PostgresFactory or MySqlFactory builds the matching trio so they speak the same protocol.
• Light / dark / branded theming — exactly the prototype's case: one factory per theme, and every widget it produces is guaranteed to share the look.