Abstract Factory Pattern

# CHAPTER 8

Abstract Factory Pattern #

1. Introduction #

2. Learning Objectives #

• Define the intent and specific use case of the Abstract Factory Pattern.

• Differentiate between the Factory Method (one product) and the Abstract Factory (families of products).

• Architect parallel hierarchies for abstract products and abstract factories.

• Guarantee object compatibility and cross-platform consistency.

• Implement a real-world UI element generator.

3. The Core Concept #

• The Problem: Creating individual products (like a Button) is easy. Ensuring that the Button matches the Checkbox, which matches the Scrollbar, requires systemic control.

• The Solution:

1. 1. Explicitly declare interfaces for each distinct product in the family (e.g., Button, Checkbox).

1. 2. Declare the *Abstract Factory*—an interface with a list of creation methods for all products in the family (e.g., createButton(), createCheckbox()).

1. 3. Create concrete factories for each variant (e.g., MacFactory, WindowsFactory).

4. Families and Variants #

• Families (The Concepts): Chair, Sofa, Coffee Table.

• Variants (The Themes): Modern, Victorian, Art Deco.

• *The Rule:* A ModernFactory can only create a Modern Chair, Modern Sofa, and Modern Table. It is architecturally impossible for the ModernFactory to accidentally return a Victorian Chair.

5. Why is this powerful? #

• Guaranteed Consistency: You eliminate the risk of a developer accidentally mixing and matching incompatible products.

• Client Isolation: The client code (the main app) only talks to the GUIFactory interface and the Button interface. It has absolutely no idea if it is running on Mac or Windows.

6. UML Diagram #

                     [ <<Interface>> AbstractFactory ]
                     + createButton(): Button
                     + createCheckbox(): Checkbox
                                ^
          ---------------------------------------
          |                                     |
[ ConcreteFactory1 (Mac) ]            [ ConcreteFactory2 (Win) ]
+ createButton() { new MacBtn }       + createButton() { new WinBtn }
+ createCheckbox() { new MacChk }     + createCheckbox() { new WinChk }

7. Code Example (PHP) #

<?php
// --- 1. Abstract Products ---
interface Button {
    public function render();
}
interface Checkbox {
    public function toggle();
}

// --- 2. Concrete Products (Mac Variant) ---
class MacButton implements Button {
    public function render() { echo "Rendering an Apple style button.\n"; }
}
class MacCheckbox implements Checkbox {
    public function toggle() { echo "Toggling an Apple style checkbox.\n"; }
}

// --- 3. Concrete Products (Windows Variant) ---
class WindowsButton implements Button {
    public function render() { echo "Rendering a Microsoft style button.\n"; }
}
class WindowsCheckbox implements Checkbox {
    public function toggle() { echo "Toggling a Microsoft style checkbox.\n"; }
}

// --- 4. The Abstract Factory ---
interface GUIFactory {
    public function createButton(): Button;
    public function createCheckbox(): Checkbox;
}

// --- 5. Concrete Factories ---
class MacFactory implements GUIFactory {
    public function createButton(): Button { return new MacButton(); }
    public function createCheckbox(): Checkbox { return new MacCheckbox(); }
}

class WindowsFactory implements GUIFactory {
    public function createButton(): Button { return new WindowsButton(); }
    public function createCheckbox(): Checkbox { return new WindowsCheckbox(); }
}

// --- 6. Client Code ---
// The application doesn't care which OS it's on. It just uses the factory it's given.
class Application {
    private $button;
    private $checkbox;

    public function __construct(GUIFactory $factory) {
        $this->button = $factory->createButton();
        $this->checkbox = $factory->createCheckbox();
    }

    public function renderUI() {
        $this->button->render();
        $this->checkbox->toggle();
    }
}

// Bootstrapping the app based on environment
$os = "Windows"; // Imagine this is dynamically detected
$factory = ($os === "Mac") ? new MacFactory() : new WindowsFactory();

$app = new Application($factory);
$app->renderUI();
// Output:
// Rendering a Microsoft style button.
// Toggling a Microsoft style checkbox.
?>

8. Best Practices #

• Dependency Injection: The client code (the Application class in our example) should almost never instantiate the concrete factory itself. The factory should be instantiated once at the very top level of the application (the bootstrap/config layer) and *injected* into the client.

9. Common Mistakes #

• The "Everything" Factory: An architect adds 50 different create...() methods to the Abstract Factory, forcing concrete factories to implement massive amounts of code. *The Failure:* This violates the Interface Segregation Principle (ISP). If a new platform only supports 10 of those UI elements, it has to write 40 useless, empty methods. *The Fix:* Keep Abstract Factories focused on highly cohesive, strictly related product families.

10. Mini Project: Build an RPG Equipment Generator #

1. 1. Abstract Products: Create Weapon (method: attack()) and Armor (method: defend()).

1. 2. Variants: Create concrete products for "Knight" (Sword, PlateArmor) and "Wizard" (Staff, Robe).

1. 3. Abstract Factory: Create EquipmentFactory.

1. 4. Concrete Factories: Create KnightFactory and WizardFactory.

1. 5. Client: Write a script that accepts a factory, creates a full set of gear, and executes attack() and defend(), proving the Wizard cannot accidentally equip Plate Armor.

11. Practice Exercises #

1. 1. Define the core architectural problem that the Abstract Factory pattern solves which the standard Factory Method pattern does not.

1. 2. Explain how the Abstract Factory pattern guarantees "product consistency" across a software application.

12. MCQs with Answers #

13. Interview Questions #

• Q: Compare and contrast the Factory Method pattern with the Abstract Factory pattern. Give a specific real-world scenario where you would explicitly choose Abstract Factory over Factory Method.

• Q: Walk me through the consequences of needing to add a *new product type* (e.g., adding createDropdown()) to an existing Abstract Factory architecture. Why is this considered a weakness of the pattern? (Hint: It breaks OCP for the interfaces).

• Q: Explain how the Abstract Factory pattern heavily utilizes the Dependency Inversion Principle (DIP) to decouple the UI logic from the Operating System.

14. FAQs #

15. Summary #

16. Next Chapter Recommendation #