Abstract Factory Pattern

One factory object creates a whole family of parts that are made to go together, so a client never mixes a light button with a dark checkbox.

Overview

Abstract Factory is a creational pattern from the Gang of Four book (Gamma, Helm, Johnson and Vlissides, *Design Patterns*, 1994). Where Factory Method creates one product, Abstract Factory creates a set of products that belong together: every widget of one theme, every driver piece for one database, every parser for one file format.

The client holds one factory object and asks it for each part. Because one factory makes every part, the parts always match. Swapping the family means handing the client a different factory; the client's code does not change.

Interviewers use this pattern to see whether you can tell it apart from Factory Method, whether you know its one real weakness (adding a new kind of product touches every factory), and whether you can explain where the factory gets chosen.

The shape of the pattern

Each concrete factory returns its own products: LightTheme makes a LightButton and a LightCheckbox, DarkTheme makes the dark pair. Those four classes are left off the drawing to keep it readable; the table of roles below lists them.

Abstract factory — ThemeFactory: one creation method per kind of part
Concrete factory — LightTheme, DarkTheme: one per family
Abstract product — Button, Checkbox: one per kind of part
Concrete product — LightButton, DarkButton, LightCheckbox, DarkCheckbox
Client — render_login(factory): uses only the interfaces

The two directions of change

The pattern is open in one direction and closed in the other. Say this unprompted; it is the point interviewers wait for.

Add a family (a high-contrast theme) — One new factory class and its products — Easy; no existing code changes
Add a kind of part (a slider) — The factory interface and every concrete factory, plus a product per family — Hard; every family changes

So the pattern fits when the set of part kinds is stable and the set of families grows. If new kinds of parts arrive often, the interface churns and the pattern fights you.

Where you meet it for real

Java java.awt.Toolkit — The abstract superclass of the AWT implementations; getDefaultToolkit() returns the headless implementation when the java.awt.headless property is true, otherwise the platform one. Its subclasses bind components to the native toolkit
A database access layer — One family per database: connection, query builder and type mapper that all speak the same dialect
A rendering backend — One family per output: the page, table and chart writers for HTML, or for PDF

What you will be able to do

Name the five roles and draw the structure with the client on the interface side only.
Write a working Abstract Factory in Python and choose the family from configuration in one place.
State which change is cheap (a new family) and which is expensive (a new kind of part).
Choose between Factory Method and Abstract Factory for a given problem and defend the choice.

Interview questions

How does Abstract Factory stop a client from mixing families?
Abstract Factory or Factory Method: how do you choose?
What is the main drawback of Abstract Factory, and how do you soften it?
How do you pick the concrete factory at runtime, and how do you test the client?
Draw the roles for a database access layer that supports two databases.