Abstract Factory Pattern

1The problem it solves#

One scenario shows up over and over: you are building a UI toolkit and need buttons, checkboxes, and scrollbars. Then the ask lands: "support macOS and Windows, make it look native on both."

The combinatorics get ugly fast.

• Two platforms times three widget kinds is already six concrete classes (MacButton, WindowsButton, MacCheckbox, and so on).
• A third platform pushes it to nine.
• Each one is a class you now have to create from somewhere.

The naive version branches everywhere. At every spot you build a widget you write:

if (platform == MAC) {
    button = new MacButton();
} else {
    button = new WindowsButton();
}

• You write that same if for the checkbox. And the scrollbar. And the menu.
• Three widget kinds and two platforms means three copies of the same branch, each a place a future bug can hide.
• The branching spreads through the whole codebase like mold.

There are two real problems underneath, and the second is the sneaky one.

• Open/Closed violation. Business code knows every concrete class, so a third platform means editing the branch in every file. You cannot extend the system without reopening existing code.
• No pairing guarantee. Nothing stops you from pairing a MacButton with a WindowsCheckbox. The families are supposed to stay together, but the type system lets you mix them freely. The compiler will never catch that bug.

2The idea (mental model)#

Think of a kit. When you buy a furniture kit you get screws, bolts, and panels that all fit each other. You do not pick a screw individually and hope it matches the panel. The kit guarantees the fit.

• An abstract factory is that kit: an object whose entire job is to hand you a set of parts that belong together.
• You never say "give me a MacButton." You say "give me a button" to the Mac kit, and it decides.
• The one line to keep in your head: a factory of consistent sets. Choose the set once, at startup, and every part you pull after that is guaranteed to be from the same family.

Two principles do the heavy lifting.

• Dependency Inversion. The client depends on the Button and GUIFactory abstractions, never on MacButton.
• Single Responsibility. The only thing that knows how to build a family is the factory for that family, so widget-building logic lives in one place per platform, not scattered across the app.

Interviewers love this exact distinction, so have the one-liner ready: Factory Method is one hook; Abstract Factory is a whole menu of hooks bundled behind one interface.

3Structure#

The moving parts, each with one job:

• Abstract Factory. An interface that declares one creation method per product kind: createButton(), createCheckbox().
• Concrete Factories. One per family: MacFactory, WindowsFactory. Each returns that family's products.
• Abstract Products. The interfaces for each kind of thing: Button, Checkbox.
• Concrete Products. The actual classes: MacButton, WindowsCheckbox.
• Client. Your code. Holds a reference to the abstract factory and the abstract products, and never mentions a concrete class.

The key move: the client depends only on interfaces.

• The concrete factory is injected once, usually at the composition root.
• Everything downstream stays blind to which family it got.
• That single injection point is where the design earns its testability: pass a fake factory in a unit test and the client never knows the difference.

4Implementation in Java#

Start with the product interfaces. Keep them small.

interface Button {
    void render();
}

interface Checkbox {
    void render();
}

Now the concrete products, one set per platform.

class MacButton implements Button {
    public void render() {
        System.out.println("Rounded macOS button");
    }
}

class MacCheckbox implements Checkbox {
    public void render() {
        System.out.println("macOS checkbox with a soft check");
    }
}

class WindowsButton implements Button {
    public void render() {
        System.out.println("Square Windows button");
    }
}

class WindowsCheckbox implements Checkbox {
    public void render() {
        System.out.println("Windows checkbox with a hard tick");
    }
}

The factory interface. One method per product kind. This is the whole contract, and its size is the thing to watch: every method here must be implemented by every concrete factory, so this interface is the pattern's cost center.

interface GUIFactory {
    Button createButton();
    Checkbox createCheckbox();
}

Two concrete factories. Each produces only its own family, so the pairing can never go wrong.

class MacFactory implements GUIFactory {
    public Button createButton() {
        return new MacButton();
    }
    public Checkbox createCheckbox() {
        return new MacCheckbox();
    }
}

class WindowsFactory implements GUIFactory {
    public Button createButton() {
        return new WindowsButton();
    }
    public Checkbox createCheckbox() {
        return new WindowsCheckbox();
    }
}

The client. Notice it never says new MacButton(). It takes a factory, builds its parts, and uses them, with no idea which platform it is on.

class Application {
    private final Button button;
    private final Checkbox checkbox;

    Application(GUIFactory factory) {
        this.button = factory.createButton();
        this.checkbox = factory.createCheckbox();
    }

    void renderUI() {
        button.render();
        checkbox.render();
    }
}

• That GUIFactory in the constructor is textbook constructor injection.
• It is why you can test Application against a stub factory with zero production classes involved.

The one place that picks the family. This is the composition root, the single spot allowed to know about concrete factories.

public class Main {
    public static void main(String[] args) {
        String os = System.getProperty("os.name").toLowerCase();
        GUIFactory factory = os.contains("mac")
            ? new MacFactory()
            : new WindowsFactory();

        Application app = new Application(factory);
        app.renderUI();
    }
}

Here is the runtime flow for one call, so you can see how the request travels:

5A real-world example#

The classic is cross-platform UI, and it is classic because it is true.

• Java's own Swing look-and-feel system works on this idea: a LookAndFeel object produces a matching set of UI delegates so your buttons, sliders, and menus all share one visual language.
• Switch the LookAndFeel and the whole set changes together. That is the pattern in production in the standard library.

It works well outside UI too. Cloud providers are a clean fit.

• One project needed a storage client, a queue client, and a secrets client, all from the same provider or nothing lined up.
• The build: a CloudFactory with createStorage(), createQueue(), and createSecrets().
• AwsFactory returned S3, SQS, and Secrets Manager wrappers. GcpFactory returned the Google equivalents.
• The app got one factory at boot, from config, and never cared again. Swapping providers in a test became a one-line change: pass the other factory, replacing what would have been three coordinated client swaps.

Database access layers that support more than one engine are another good fit.

• A PostgresFactory and a MySqlFactory each hand back a connection, a query builder, and a dialect object that all speak the same SQL flavor.
• You never accidentally feed MySQL syntax to a Postgres connection, because the factory will not give you that mismatched pair.

The common thread in all three: a set of parts that must stay consistent, and a single decision point that picks the set.

6When to use it, and when not to#

Use it when:

• You have two or more product kinds that come in matching families, and mixing families across the line is a bug.
• You want to swap the whole set at once, at runtime or by config, without touching client code.
• The concrete classes are a detail your business logic should not know.

Skip it when:

• You only have one product kind. Then you want Factory Method or a plain factory. Abstract Factory earns its keep only when the family has multiple members.
• The families never actually vary. One platform that will only ever be one platform makes this ceremony with no payoff: a kit factory that produces a single kit.
• Adding a new product kind is more likely than adding a new family. This is the pattern's real weakness, covered next.

7Common mistakes#

Confusing it with Factory Method.

• The single most common slip. Factory Method overrides one creation step through inheritance.
• Abstract Factory bundles several creation methods behind one interface, held by composition, to produce a whole family.
• If someone's "abstract factory" has one create method, it is really a factory method.

Letting concrete classes leak into the client.

• If Application ever writes new MacButton() or casts a Button down to MacButton, the pattern is broken.
• One sneaky instanceof check and you have undone it, because now the client knows the family and you are back to the branching you started with.

Overbuilding too early.

• People reach for this when there is one family and a vague "maybe someday" second one, ending up with four interfaces and six classes to produce one button.
• Build the simple version first. Introduce the factory when the second family actually arrives and the pattern pays for itself.

Forgetting the families must stay matched.

• If your MacFactory can somehow return a WindowsCheckbox, you have thrown away the guarantee that justifies the pattern.
• Each concrete factory must return only its own family, always. The guarantee is only as strong as the weakest factory.

Scattering the family choice.

• The if os == mac check should exist in exactly one place.
• Select the factory in three different files and you have recreated the original mess one level up, just with fancier types.

Next, compare this with the Factory Method and Builder patterns, and try applying it to a notification-service or payment-gateway design problem.