Abstract Factory Pattern

Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

Intent & Objective

Produce families of related objects (such as UI buttons, checkboxes, and windows) without depending on their concrete implementations, ensuring products from one family are never accidentally mixed with another.

👥 Real-World Human Analogies & Social Roles

2 Intuitive Scenarios

Themed Furniture Store Interior Design

"You can furnish a room in Modern, Victorian, or Industrial styles. The Modern factory creates a matching chair and table; the Victorian factory creates ornate mahogany sets, avoiding aesthetic clashes."

Cross-Platform UI Toolkit GUI Frameworks

"Creating a family of Windows Fluent controls vs macOS Aqua controls, guaranteeing a window never pairs a Mac button with a Windows scrollbar."

The Problem

When creating suites of related components, client code might accidentally instantiate a Windows Button with a macOS Scrollbar, creating visual and behavioral inconsistencies.

The Solution

Define an Abstract Factory interface declaring creation methods for each product in the family (`createButton()`, `createCheckbox()`). Implement concrete factory classes for each family variant.

Key Participants & Architectural Roles

Abstract Factory

Declares methods for creating abstract product family members

Concrete Factories

Implement operations to build concrete product variants

Abstract Products

Declare interfaces for distinct product types (e.g. Button, Scrollbar)

Client

Uses only interfaces declared by Abstract Factory and Abstract Product

Code Samples (Traditional OOP vs Functional Programming)

Available in C++, Python, and Java

Paradigm Contrast: Traditional OOP vs Functional / Data-Oriented

In OOP, Abstract Factory is a class containing multiple factory methods. In Functional Programming, an Abstract Factory is represented as a record/tuple of constructor functions or a module signature providing a cohesive set of builders.

Advantages

✓ Guarantees compatibility between products of the same family
✓ Isolates concrete product classes from client code
✓ Follows Single Responsibility and Open/Closed principles

Trade-offs

✗ Extending the factory to add new product types requires changing the Abstract Factory interface and all its subclasses

When to Apply

→ When your system must support multiple independent visual themes, cross-platform UI toolkits, or database drivers
→ When you need to enforce that product variants work together harmoniously

When to Avoid

! When you only have one single product type rather than families of related components