Abstract factory pattern

Introduction

Abstract Factory is a creational pattern for creating a set of related products through one family-specific interface. The client depends on product interfaces and selects a concrete factory at the composition root.

TL;DR / mental model: Treat a factory as a product-family kit: choose WindowsFactory, MacFactory, or another family once, then ask that factory for each product so the objects used together share the same configuration.

Problem and Context

Your UI toolkit needs to support multiple platforms: Windows, macOS, and Linux. Each platform has its own Button, Checkbox, and TextField. Widgets within a platform must be compatible with each other. Mixing a macOS button with a Windows checkbox produces rendering glitches and inconsistent behavior.

Without the pattern, you end up with scattered if/else blocks and nothing preventing cross-family mixing:

Abstract Factory addresses this by grouping creation for one family behind a single factory. When the application obtains its products through that factory, the composition root has one place to choose the family and the client avoids manually pairing concrete products from different families. The concrete factory still has to implement its contract consistently.

A concise distinction is: Factory Method creates one product; Abstract Factory creates a related family of products. The important design property is that the family is selected as a unit.

When It Helps

Use Abstract Factory when several related product types vary together—for example, Button, Checkbox, and TextField for one platform—and client code should not depend on concrete products. If there is only one product type or one fixed implementation, a simpler factory or direct construction is usually clearer.

---

Participants and Structure

UIFactory declares one create method per product type. Each concrete factory (like WindowsFactory) returns products from its own family. The application receives a UIFactory through its constructor and never names any concrete product class. Swapping the entire look-and-feel means passing a different factory at startup.

Notice the diagram has two parallel hierarchies: one for factories (left side) and one for products (right side). Each concrete factory knows how to create its own family's concrete products. The client only navigates the abstract layer (interfaces at the top).

---

Idiomatic Example and Implementation Notes

The full implementation requires three layers: abstract products (interfaces), concrete products (platform-specific classes), and concrete factories (one per platform). This looks like a lot of classes, but each one is small and focused. The key insight: the application layer only touches interfaces.

Start with the Application.java file to see how the client uses the factory, then trace back to see how the products are created. This makes the dependency direction clear: application code uses abstractions, while the composition root selects a concrete family.