Abstract Factory Pattern
Provide an interface for creating families of related or dependent objects without specifying their concrete classes. Ensures products within a family are compatible.
Abstract Factory = IKEA vs Pottery Barn. Pick a store (factory) and everything you buy — table, chair, lamp — matches the same style. You never mix IKEA legs with Pottery Barn tops.
Abstract Factory groups related factories behind an interface. A UIFactory might have createButton() and createCheckbox(); WindowsUIFactory and MacUIFactory provide platform-consistent implementations. The client works exclusively through the UIFactory interface — swap the factory, get a different look-and-feel without touching a single client line. This is one level above Factory Method: instead of deferring one product, you defer an entire product family.
Abstract Factory is the pattern when the constraint is product family consistency. If a client should never mix MacButton with WindowsCheckbox, an Abstract Factory enforces that constraint structurally: the factory for Windows only produces Windows widgets. The trade-off: adding a new product type (createScrollbar()) requires changing the AbstractFactory interface and all its implementations — a violation of OCP. Abstract Factory shines when the set of products is fixed and the set of platforms varies. The pattern is common in cross-platform UI toolkits (AWT, SWT), database connector families (JPA providers), and testing (a TestDoubleFactory that produces mocks and stubs with consistent wiring).
I use Abstract Factory when I need to guarantee a family of products is internally consistent. In a cross-platform UI: AbstractUIFactory declares createButton(), createDialog(), createTextField(). WindowsFactory and MacFactory each produce platform-specific widgets. The application bootstraps by selecting the factory based on OS, then every component is created through that factory — no mixing. The downside I always flag: extending the product family (new widget type) requires changes to every concrete factory, so this pattern is best when the family is stable.
Abstract Factory vs Factory Method: Abstract Factory is for families of products (multiple product types, one factory per platform). Factory Method is for a single product type (one product, creation deferred to a subclass). Conflating them is the #1 interview mistake on creational patterns.