Abstract Factory Pattern: Creating Families of Related Objects

Abstract Factory Pattern

Abstract Factory provides an interface for creating families of related or dependent objects without specifying their concrete classes. Where Factory Method answers "which one class do I build?", Abstract Factory answers "which entire matching set of classes do I build, so they're guaranteed compatible with each other?" The pattern's whole value proposition is that consistency guarantee — it makes it structurally impossible to accidentally mix incompatible objects from different families.

1. Intent

Some objects only make sense in matched sets: a UI theme's button must never appear next to a checkbox from a different theme; a database access layer's Connection, Statement, and ResultSet implementations must all come from the same driver. Abstract Factory's intent is to bundle the creation of every product in such a family behind one factory interface, so a client that asks for "the button" and "the checkbox" from the same factory instance is guaranteed to get a compatible pair — without ever naming a concrete class.

2. The Naive Approach (Violation)

// VIOLATION: client code decides each widget's concrete type independently —
// nothing stops a caller from accidentally mixing families.
class SettingsDialog {
    private Button button;
    private Checkbox checkbox;
 
    SettingsDialog(String theme) {
        if (theme.equals("DARK")) {
            button = new DarkButton();
        } else {
            button = new LightButton();
        }
        // Copy-paste bug: this branch was never updated when DARK was added elsewhere —
        // checkbox stays LightCheckbox even when theme == "DARK".
        checkbox = new LightCheckbox();
    }
}

The bug here is exactly the kind Abstract Factory eliminates by construction: it's not a logic error inside one if, it's a consistency error across two independent creation decisions that happen to need to agree but have no mechanism forcing them to. As more widget types are added (Slider, Dropdown, RadioButton), the number of independent decisions that must all stay in sync grows, and so does the chance one gets missed.

3. Structure

Each row of the family (Button, Checkbox, ...) is an abstract product with one concrete implementation per family. Each column (LightWidgetFactory, DarkWidgetFactory) is a concrete factory that implements the entire WidgetFactory interface, guaranteeing every product it hands out belongs to the same family.

4. Java Implementation

// Abstract products
interface Button {
    void render();
}
interface Checkbox {
    void render();
}
 
// Light family
class LightButton implements Button {
    public void render() { System.out.println("Rendering light button"); }
}
class LightCheckbox implements Checkbox {
    public void render() { System.out.println("Rendering light checkbox"); }
}
 
// Dark family
class DarkButton implements Button {
    public void render() { System.out.println("Rendering dark button"); }
}
class DarkCheckbox implements Checkbox {
    public void render() { System.out.println("Rendering dark checkbox"); }
}

// Abstract Factory
interface WidgetFactory {
    Button createButton();
    Checkbox createCheckbox();
}
 
// Concrete factories — each one guarantees an internally consistent family
class LightWidgetFactory implements WidgetFactory {
    public Button createButton() { return new LightButton(); }
    public Checkbox createCheckbox() { return new LightCheckbox(); }
}
 
class DarkWidgetFactory implements WidgetFactory {
    public Button createButton() { return new DarkButton(); }
    public Checkbox createCheckbox() { return new DarkCheckbox(); }
}

// FIXED: SettingsDialog only ever talks to ONE factory instance —
// mixing families is now structurally impossible, not just "avoided by discipline."
class SettingsDialog {
    private final Button button;
    private final Checkbox checkbox;
 
    SettingsDialog(WidgetFactory factory) {
        this.button = factory.createButton();
        this.checkbox = factory.createCheckbox();
        // Both come from the same factory instance — guaranteed matched theme.
    }
 
    void render() {
        button.render();
        checkbox.render();
    }
}
 
// Usage — the choice of family happens ONCE, at composition time:
WidgetFactory factory = userPrefersDarkMode ? new DarkWidgetFactory() : new LightWidgetFactory();
SettingsDialog dialog = new SettingsDialog(factory);
dialog.render();

5. Extending Abstract Factory: The Two Growth Axes

Abstract Factory has an asymmetric extensibility profile that's important to understand and is a favorite interview follow-up:

// Adding a new FAMILY is cheap and open/closed-compliant:
class HighContrastWidgetFactory implements WidgetFactory {
    public Button createButton() { return new HighContrastButton(); }
    public Checkbox createCheckbox() { return new HighContrastCheckbox(); }
}
// Zero existing classes were modified.

// Adding a new PRODUCT KIND (e.g. Slider) requires editing the interface itself
// AND every existing concrete factory — this direction violates OCP:
interface WidgetFactory {
    Button createButton();
    Checkbox createCheckbox();
    Slider createSlider(); // NEW — breaks LightWidgetFactory and DarkWidgetFactory
                            // until each is updated to implement it
}

6. When to Use vs. When It's Overkill

7. Abstract Factory vs. Factory Method

Restating the core distinction from the other side, since this is commonly asked to be explained both ways:

8. Real-World / Production Examples

• javax.xml.parsers.DocumentBuilderFactory / SAXParserFactory — each returns a family of XML-processing objects consistent with one underlying parser implementation.
• Cross-platform GUI toolkits (Swing's pluggable LookAndFeel, or historically AWT Toolkit) — one factory per platform/theme producing a consistent set of widget implementations.
• JDBC driver families — a driver's Connection, PreparedStatement, and ResultSet implementations are all created consistently for one database vendor; mixing a MySQL Connection with a PostgreSQL ResultSet implementation isn't meaningful, and Abstract Factory-style driver registration prevents it.
• Cloud SDK client factories — an SDK that produces a family of service clients (storage, compute, networking) all configured consistently for one account/region/credential set via a single factory/builder entry point.
• Testing: an InMemoryRepositoryFactory vs JdbcRepositoryFactory, each producing a consistent family of repository implementations (OrderRepository, UserRepository, ...) so tests never accidentally mix a real DB repository with an in-memory one.

Interview Questions

• What's the precise difference between Factory Method and Abstract Factory — not just "one vs many," but why that difference exists structurally?
• Walk through the "mismatched pair" bug that Abstract Factory prevents, and explain exactly which line of naive code introduces the risk.
• Why is adding a new product kind (not family) expensive under Abstract Factory? What has to change?
• Why is adding a new family cheap under Abstract Factory, and how does that satisfy the Open/Closed Principle?
• How is Abstract Factory often implemented internally in terms of Factory Method?
• Give a real-world example where using two objects from different families (mixing them) would cause a real bug, and explain how Abstract Factory prevents it structurally rather than by convention.
• When would you choose a simpler parameterized factory or direct construction over Abstract Factory, even though objects technically come in families?