The Abstract Factory
builds whole families of things —
without the client ever picking parts.

A design pattern is a reusable solution to a recurring object‑oriented design problem in a given context — a template, not finished code. It is not the same as an architectural pattern/style: architecture is about the shape of the whole system; a design pattern solves one recurring problem inside the detailed design.

Full pattern docs list categories like IntentMotivationApplicabilityStructureParticipantsCollaborationsConsequencesImplementationSample CodeKnown UsesRelated Patterns. For this course, you only need the gist: what problem it solves, who the players are, and how they collaborate — not the full formal write‑up.

Creational patterns abstract and control how objects are created, hiding the concrete classes behind a common creational interface.

Intent: provide an interface for creating families of related objects — without the client ever naming their concrete classes.

It's an object‑level, creational pattern, made of two class hierarchies working as a pair:

Problem: a UI must support a Dark theme and a Light theme, each with its own Button and TextField, without scattering if (dark) … else … everywhere.

• Products = Button, TextField
• Factories = DarkThemeFactory, LightThemeFactory
• The client asks the factory for a Button/TextField and never checks which concrete class comes back.
• Add a BlueTheme tomorrow → add BlueThemeFactory + BlueButton + BlueTextField. Zero client‑code changes.

// Step 1 — Abstract Factory interface
interface GUIFactory {
    Button createButton();
    TextField createTextField();
}

// Step 2 — Concrete Factories, one per theme
class DarkThemeFactory implements GUIFactory {
    Button createButton() { return new DarkButton(); }
    TextField createTextField() { return new DarkTextField(); }
}

class LightThemeFactory implements GUIFactory {
    Button createButton() { return new LightButton(); }
    TextField createTextField() { return new LightTextField(); }
}

// Step 5 — Client only ever talks to the interfaces
GUIFactory factory = new DarkThemeFactory(); // swap this line only
Button   btn = factory.createButton();
TextField tf = factory.createTextField();

A computer store sells two families of computers: Advanced and Standard. Each family bundles a Cpu, Monitor, and Keyboard that must stay consistent with each other and pull their info from different data sources.

class ComputerStore {
    Monitor  monitor;
    Cpu      cpu;
    Keyboard keyboard;

    ComputerStore(ComputerPartsFactory factory) {
        // the store never knows if "factory" is Advanced or Standard
        monitor  = factory.createMonitor();
        cpu      = factory.createCpu();
        keyboard = factory.createKeyboard();
    }
}

// main()
ComputerPartsFactory f = (option == 1)
    ? new AdvancedComputerPartsFactory()
    : new StandardComputerPartsFactory();

ComputerStore store = new ComputerStore(f);

Build‑order checklist (memorize this order!)

1. Design the product interfaces — Cpu, Monitor, Keyboard.
2. Identify the families/groups — e.g. Standard vs. Advanced.
3. Write concrete products for each family, implementing step 1's interfaces.
4. Create the factory interface — one creation method per product from step 1.
5. Write a concrete factory per family, implementing step 4's interface.
6. Wire each concrete factory to its own products from step 3.
7. Build the Client, depending only on the interfaces from steps 1 and 4.

Riyadh HQ (the client) only ever talks to a CarFactory interface with makeMercedes() and makeBMW(). It never touches JeddahCarFactory or DammamCarFactory directly.

• Why HQ doesn't care who builds the car: HQ codes against the abstract CarFactory, Mercedes, and BMW types — the concrete branch is an implementation detail hidden behind those interfaces.
• Why it's easy to switch branches at runtime: swapping JeddahCarFactory for DammamCarFactory is a one‑line change (which object gets assigned) — no recompiling or editing of HQ's logic.
• Why this is Abstract Factory: two concrete factories (branches) each produce their own consistent family of two related products (Mercedes + BMW), behind one shared interface.

Yes — DarkButton, LightButton, DarkThemeFactory, etc. all get written somewhere. The pattern's promise isn't "no concrete classes exist" — it's that the client never mentions their names. The client only ever declares variables of the abstract types (Button, GUIFactory…), so adding a brand‑new family later touches zero client code.

This chapter covered pattern fundamentals (purpose vs. scope, documentation categories) and the first creational pattern: Abstract Factory — one interface, many families, client stays blind to the concrete classes.

Up next in Creational Patterns: Factory MethodBuilderSingleton