1.2 Abstract Factory
If Factory Method is about creating one product, Abstract Factory is about creating a whole family of products that must go together.
The classic example is cross-platform UI: on Windows, the button, scrollbar, and menu should all have the Windows look and feel; on macOS, the matching macOS set. You never want a "Windows button next to a macOS scrollbar" mismatch. The core guarantee of Abstract Factory is exactly this: every product from one factory is guaranteed to belong to the same family.
In the theme kit factory below, switching the theme swaps an entire set of coordinated widgets — button, checkbox, and card reskin together.
Structure: a factory of factories
Abstract Factory adds one more layer of abstraction on top of factory methods:
interface GUIFactory {
Button createButton();
Checkbox createCheckbox();
}
class LightFactory implements GUIFactory {
public Button createButton() { return new LightButton(); }
public Checkbox createCheckbox() { return new LightCheckbox(); }
}
class DarkFactory implements GUIFactory {
public Button createButton() { return new DarkButton(); }
public Checkbox createCheckbox() { return new DarkCheckbox(); }
}The client holds a GUIFactory interface and calls createButton() and createCheckbox(), with no idea whether it is using Light or Dark. To reskin everything, swap the single factory instance at the outermost layer.
Consistency is the real selling point
The first time people see Abstract Factory they often think "isn't this just a few factory methods bundled together?" Its value isn't in lines of code — it's in the constraint: when every product comes from one factory, you eliminate cross-family mixing at compile time.
The consistency checker below lets you hand-pick a source for each widget. The instant you mix implementations from different operating systems, it raises an alarm — while the "align via factory" buttons show how an abstract factory removes that mistake at the source.
The cost: adding a new product kind is expensive
Abstract Factory has a famous weakness: adding a new kind of product (say, a Slider in addition to buttons and checkboxes) is painful, because you must change the GUIFactory interface and every concrete factory that implements it.
So it fits when:
- the kinds of products are relatively stable (button, checkbox rarely change);
- but the families grow often (Light/Dark today, Cyber and a high-contrast accessibility theme tomorrow).
If the reverse is true — kinds churn while families are stable — Abstract Factory will fight you at every step.