Abstract Factory

The Abstract Factory Pattern is a creational design pattern that provides an interface for creating families of related or dependent objects without specifying their concrete classes. It is often referred to as a "Factory of Factories," encapsulating a group of individual factories that share a common theme.

1. Learning Objectives

• Identify when to apply the Abstract Factory pattern to group related objects.
• Synthesize abstract interfaces defining multiple polymorphic factory methods.
• Prevent configuration conflicts between incompatible object types.
• Analyze the tradeoffs of adding new products to an existing factory interface.
• Implement type-safe, multi-product family suites in Java, Python, and C++.

2. Problem & Naive Solution

Consider a cross-platform user interface (UI) rendering library. It must support multiple operating systems (e.g., Windows, macOS, Linux). Each platform has a distinct visual style for widgets: Buttons, TextFields, and Checkboxes.

The Naive Solution

A developer might implement different platform classes and instantiate them based on system checks:

This introduces significant coupling:

• Incompatibility Risks: If a developer makes a mistake and instantiates a WindowsButton alongside a MacCheckbox, the UI will look inconsistent, and platform-specific event hooks might crash.
• Violates Open/Closed Principle: Adding support for a new platform (e.g. Android) forces us to modify the conditional logic in every client dashboard class.
• Scattered Instantiations: The client must know about every concrete widget class (e.g. WindowsButton, MacCheckbox), making the codebase hard to maintain.

3. Issues

When client code is tied directly to concrete product classes, swapping platform styles requires refactoring the entire client codebase. It also makes it easy to accidentally mix components from different platforms, leading to visual bugs and runtime crashes.

4. Pattern Introduction & UML

The Abstract Factory Pattern solves these issues by defining an interface for creating families of related products. Instead of instantiating widgets directly, the client depends on an abstract factory interface:

• Abstract Factory (UIFactory): Declares creation methods for each product type.
• Concrete Factories (WindowsUIFactory, MacUIFactory): Implement the factory methods to return platform-specific product instances.
• Abstract Products (Button, Checkbox): Declare interfaces for each product type.
• Concrete Products (WindowsButton, MacButton): Implement the product interfaces for specific platforms.

5. Participants

• Abstract Factory (UIFactory): Defines the factory interface containing creation methods for the product family.
• Concrete Factory (WindowsUIFactory): Implements the factory methods to create concrete products for a specific platform family.
• Abstract Product (Button): Defines the product interface for a widget type.
• Concrete Product (WindowsButton): Implements the product interface for a specific platform family.
• Client (Application): Interacts only with the abstract factory and product interfaces.

6. Theory (Factory Method vs. Abstract Factory)

Understanding the differences between these two patterns is a common interview topic:

• Factory Method: Focuses on creating a single product type. It relies on class inheritance, delegating instantiation to creator subclasses overriding a virtual method.
• Abstract Factory: Focuses on creating families of related products. It relies on object composition, providing an interface containing multiple factory methods that the client uses to instantiate related objects.

7. Syntax Explanation

Implementing the pattern requires defining interfaces with multiple creation methods:

• Java: Declares a UIFactory interface containing methods returning abstract product types (e.g. Button createButton();).
• Python: Uses Abstract Base Classes (ABCs) to define the factory and product interfaces.
• C++: Uses pure virtual classes (e.g. virtual std::unique_ptr<Button> createButton() = 0;). Using smart pointers ensures correct memory management when instantiating polymorphic object families.

8. Step-by-Step Implementation

1. Step 1: Create the abstract product interfaces (e.g., Button, Checkbox, TextField).
2. Step 2: Implement concrete product classes for each platform family (e.g., WindowsButton, WindowsCheckbox).
3. Step 3: Declare the abstract factory interface (e.g., UIFactory) containing creation methods for each product type.
4. Step 4: Implement concrete factory classes (e.g., WindowsUIFactory, MacUIFactory) that return platform-specific product instances.
5. Step 5: Refactor client classes to accept a factory interface reference and interact only with the abstract product interfaces.

9. Complete Code (Mini Project)

10. Code Walkthrough

Let's review the key elements of the refactored code:

• The Application client class interacts only with the abstract factory interface (UIFactory) and abstract product interfaces (Button, Checkbox). It has no dependency on concrete class implementations.
• This design ensures that widgets are always instantiated from the same platform family. For instance, the WindowsUIFactory is hardcoded to return only WindowsButton and WindowsCheckbox, preventing mix-ups.
• To add support for a new operating system, we implement the product interfaces for the new platform and create a corresponding factory class. The core application logic remains unchanged.

11. Execution Flow

1. Factory Selection: The application determines the operating system environment at startup.
2. Factory Instantiation: The system instantiates the corresponding concrete factory (e.g. WindowsUIFactory).
3. Client Initialization: The client Application constructor executes, invoking the factory methods to create the widgets.
4. Polymorphic Creation: The concrete factory instantiates and returns the platform-specific widgets.
5. Execution: The client executes the operations on the widgets, and the runtime dynamic dispatch resolves the correct platform-specific render calls.

12. Internal Working (JVM & Vtables)

At compile and runtime, families of objects are managed by the runtime virtual dispatch system:

• Parallel Vtables: The compiler generates vtables for the factory interface and each product interface. The concrete classes override these table entries.
• Cache Optimization: Since abstract factories create multiple related objects, runtimes use inline cache hits to optimize virtual table offsets for the selected factory class, reducing call latency.

13. Complexity Analysis

• Time Complexity: $O(1)$ constant time for family instantiations.
• Space Complexity: $O(F \times P)$ compile-time memory overhead, where $F$ is the number of concrete families and $P$ is the number of product interfaces. This is the cost of managing the parallel class hierarchies.

14. Best Practices

• Enforce Object Families Compatibility: Use the Abstract Factory pattern whenever object families must work together without mixing.
• Combine with Singleton: Implement concrete factories as Singletons (e.g. WindowsUIFactory), as we only need one factory instance to manage object creation.
• Keep Factory Interfaces Cohesive: Group only related products inside a factory interface. Avoid bloating the factory with unrelated class creations.

15. Common Mistakes

• Adding new products frequently: Adding a new product type (e.g. RadioButton) to the UIFactory interface forces us to modify the interface and update every concrete factory class, violating OCP.
• Mixing product families: Allowing clients to bypass factories and instantiate concrete product classes directly, leading to configuration conflicts.
• Over-engineering simple projects: Using the Abstract Factory pattern when the application only supports a single platform family.

16. Framework Usage

• Java XML Parsers: The DocumentBuilderFactory class acts as an abstract factory, allowing developers to configure and obtain parser instances from different vendor families.
• JDBC Database Connection Drivers: JDBC acts as a unified abstract factory interface. Subclasses (MySQL Connector, PostgreSQL Connector) provide concrete implementations for connection, statement, and result set product families.

17. Interview Discussion

18. Practice Exercises

• Easy: Add a new concrete factory LinuxUIFactory and its corresponding button/checkbox products to the Python example.
• Medium: Design a C++ ThemeFactory that returns DarkTheme and LightTheme components (Scrollbar, Toolbar, Panel) that must match.
• Hard: Design an abstract database driver family in Java containing Connection, Command, and DataReader interfaces. Implement concrete families for MySQL and Oracle, and write validation to verify that an Oracle Command cannot be run on a MySQL Connection.

19. Challenge Problem

Design a Multi-Cloud Deployment Broker using the Abstract Factory pattern. The broker instantiates cloud compute services (e.g. AWS EC2, Azure VM), storage engines (e.g. AWS S3, Azure Blob Storage), and security policies (e.g. AWS IAM, Azure Active Directory). The client orchestration code configures and runs virtual servers, completely isolated from cloud vendor details. Write the implementation code in Java, Python, or C++ and show how adding support for Google Cloud Platform requires zero modifications to the core orchestration code.

20. Summary & Cheat Sheet

• The Abstract Factory pattern provides an interface to instantiate families of related products without depending on concrete classes.
• It ensures compatibility across the product family, preventing mixed platform configurations.
• Client code interacts only with abstract factory and product interfaces.
• Adding new products to the factory interface violates OCP and is a key limitation of the pattern.

21. Quiz

22. Next Lesson Preview

In the next lesson, we will cover the Prototype Pattern. We will explore how to clone existing objects, avoiding expensive instantiation overhead and bypassing private attribute restrictions!