Pattern Intent and Structure

The Abstract Factory pattern offers a mechanism for creating families of related or dependent objects without specifying their concrete classes. By introducing an abstract factory interface, client code can instantiate products through a generic interface, remaining oblivious to the specific product implementations. This separation of abstraction from implementation ensures that client logic is decoupled from concrete classes.

For instance, in a database abstraction layer, the application executes standard SQL queries. The underlying database—whether MySQL, PostgreSQL, or SQLite—handles the specific implementation. The client code interacts solely with the abstract interface, swapping the database configuration without altering the business logic.

Implementation Challenges

Implementing this pattern involves defining abstract factories and abstract product classes. The hierarchy encompasses the entire family of related products, ensuring they work together through shared base classes.

While effective, the pattern has limitations. Introducing a new type of product or a new variant often requires extending the abstract factory interface and modifying every concrete factory class. If the new requirement falls outside the existing product family structure (e.g., adding a file upload feature to a database-centric factory), significant refactoring of the base classes, factories, and client code may be necessary.

Cross-Platform UI Example

Consider a scenario where an application must run on both Windows and macOS. The UI toolkit requires specific implementations for buttons and windows for each operating system. Using the Abstract Factory pattern allows the client code to create UI components without being tied to the specific OS.

1. Defining Abstract Interfaces

First, we define the abstract base classes for the UI components and the factory that creates them.

#include <iostream>
#include <memory>

// Abstract Product A
class IButton {
public:
    virtual void onPress() = 0;
    virtual ~IButton() = default;
};

// Abstract Product B
class IWindow {
public:
    virtual void render() = 0;
    virtual void close() = 0;
    virtual ~IWindow() = default;
};

// Abstract Factory
class IUIFactory {
public:
    virtual std::unique_ptr<IButton> createButton() = 0;
    virtual std::unique_ptr<IWindow> createWindow() = 0;
    virtual ~IUIFactory() = default;
};

2. Concrete Windows Implementation

Next, we implement the concrete classes for the Windows environment.

class WinButton : public IButton {
public:
    void onPress() override {
        std::cout << "WinButton: Click event detected." << std::endl;
    }
};

class WinWindow : public IWindow {
public:
    void render() override {
        std::cout << "WinWindow: Rendering native window." << std::endl;
    }
    void close() override {
        std::cout << "WinWindow: Destroying window handle." << std::endl;
    }
};

class WinFactory : public IUIFactory {
public:
    std::unique_ptr<IButton> createButton() override {
        return std::make_unique<WinButton>();
    }
    std::unique_ptr<IWindow> createWindow() override {
        return std::make_unique<WinWindow>();
    }
};

3. Client Code Usage

The client code interacts with the abstract interfaces. The specific factory implementation can be selected at compile-time or runtime based on the target platform.

int main() {
    // Determine the factory based on the compilation target
    std::unique_ptr<IUIFactory> factory;

#ifdef _WIN32
    factory = std::make_unique<WinFactory>();
#elif __APPLE__
    factory = std::make_unique<MacFactory>(); // Assuming MacFactory exists
#else
    factory = std::make_unique<DefaultFactory>();
#endif

    // The client code relies only on the abstract interfaces
    auto button = factory->createButton();
    auto window = factory->createWindow();

    button->onPress();
    window->render();
    window->close();

    return 0;
}

Practical Applications

This pattern is widely used in software engineering to maintain consistency across different system implementations.

• Database Libraries: A data access layer might provide a unified interface for connections and commands. Whether the backend is MySQL or Oracle, the client code uses the same methods to execute queries, relying on the specific factory to generate the correct connection objects.
• GUI Frameworks: Toolkits like Qt use this pattern to render controls. A QPushButton in code maps to a Windows button or a macOS Cocoa button internally, handled by the underlying factory implementation.
• Game Development: Cross-platform games may require different rendering engines (DirectX vs. Vulkan) or audio subsystems depending on the hardware (PC vs. Console). An abstract factory can instantiate the correct suite of engine components for the target platform.