Abstract factory pattern: Understanding the relationships in factories

/ LLD / By

What is abstract factory pattern?

It is a creational design pattern which works on top of the factory pattern. In this case, the client uses abstract factory to create factories that in turn create specific groups of products.

  • The Client does not create products directly; instead, it asks the factory to do it. This allows the client code to work with any concrete factory/product variant without modification.
  • The client remains completely unaware of the concrete implementation of products and factories, thus adhering to the principle of dependency inversion.

When to use Abstract Factory pattern?

The Abstract Factory pattern is particularly useful in scenarios where a system must be capable of supporting multiple families of products or needs to be configured with one among a group of multiple families. Here are five real-world use cases for the Abstract Factory pattern, with a clear distinction from the Factory Method pattern to help illustrate when and why Abstract Factory might be more appropriate:

Cross-Platform Software Development

Use Case: Developing applications that need to work seamlessly across multiple operating systems, like Windows, macOS, and Linux, with each platform requiring different types of user interface elements.
Abstract Factory Usage: Provides an interface to create families of related objects (e.g., buttons, menus, windows) without specifying their concrete classes. Each platform will have its own factory that produces all UI elements that conform to the platform’s look and feel.
Distinction from Factory Pattern: While a Factory Method might be used to create a single type of object, Abstract Factory manages the creation of multiple, related objects ensuring that all created objects are compatible with each other, which is crucial in maintaining consistent look and feel across the user interface.

Multi-Database Support in Software

Use Case: An application that needs to support multiple types of databases (e.g., MySQL, PostgreSQL, Oracle) and must allow switching between them seamlessly without altering the underlying code structure.
Abstract Factory Usage: Abstracts the process of creation of database connections, commands, and data readers/writers, allowing the application to support multiple database systems.
Distinction from Factory Pattern: The Factory Method could independently create connection objects for different databases, but the Abstract Factory can provide a suite of related products (connection, commands, readers) designed to work together, ensuring database interoperability within the application context.

Configurable Dashboard Widgets

Use Case: Software that provides customizable dashboards, where users can select from various types of widgets (charts, tables, gauges).
Abstract Factory Usage: Allows the creation of different families of widget sets where each family has a consistent style and behavior, making the dashboard components coherent.
Distinction from Factory Pattern: Instead of creating one type of widget at a time, an Abstract Factory would be used to instantiate complete families of widgets that share common themes or functionalities, which the Factory Method pattern does not directly support.

Game Development for Different Environments

Use Case: A game that can generate different levels or environments, such as forest, desert, or arctic, each requiring different types of characters, enemies, and scenery.
Abstract Factory Usage: Each environment type has a corresponding factory that creates compatible objects (characters, enemies, scenery) that fit the environment theme.
Distinction from Factory Pattern: The Abstract Factory handles the creation of groups of related products designed to work together in the game’s world, unlike the Factory Method, which would focus on creating individual objects without consideration of inter-object compatibility.

Hardware Interface Access

Use Case: Software that interfaces with different types of hardware like printers, scanners, and cameras, where each device type requires specific communication protocols or data handling.
Abstract Factory Usage: Provides an interface for creating families of related objects for device communication, ensuring that objects that need to work together do so seamlessly.
Distinction from Factory Pattern: While the Factory Method would be useful for creating a single type of device handler at a time, the Abstract Factory ensures that all created objects (like data readers, data writers, and communication handlers) are compatible with the specific hardware family, thus maintaining consistency in device handling.

In all these cases, the Abstract Factory pattern provides a way to manage families of related objects without specifying their concrete classes, making systems easy to extend and enhancing modularity. This is different from the Factory Method pattern, which focuses more on creating individual objects and is less concerned with the relationships and interoperability between them.

Why to use abstract factory pattern?

Reduction of Code Duplication

The Abstract Factory pattern allows for the consolidation of product creation logic that might otherwise be duplicated across the application. By centralizing the creation process in a single abstract factory, you reduce duplication and foster a single point of maintenance for product creation logic. This results in a cleaner codebase that’s easier to manage and update.

Increased Scalability

The pattern supports scalability by organizing product creation into families and making it straightforward to introduce new variants of products without affecting existing code. As your application grows or needs to support new types of products, you can introduce new factories without altering the client code, thus making the system more scalable.

Improved Flexibility and Interchangeability

Abstract factories increase flexibility by abstracting the creation of objects from their usage. This allows for easy swapping of entire families of products without changing the underlying codebase. For instance, switching from a set of products optimized for performance to those optimized for high security can be achieved simply by changing the factory.

Enhanced Consistency Among Products

When using the Abstract Factory pattern, products that are designed to work together are created by the same factory. This ensures that all the products sharing the same product family are compatible with each other. Such consistency is crucial, especially in environments where products need to interact closely with one another.

Decoupling of Client Code and Concrete Implementations

The client code that uses the product does not need to be aware of the concrete implementation details of the products it uses. It only interacts with the abstract interfaces provided by the factory. This separation of concerns simplifies client code, reduces its dependencies, and enhances its reliability.

Support for Principle of Inversion of Control

The pattern supports the Inversion of Control (IoC) principle, which helps in reducing the coupling between application components. The factory handles the creation logic and inversion of control, while the client remains passive in how the objects are instantiated.

Simplified Configuration of Complex Systems

Abstract factories can simplify the configuration of complex systems by centrally controlling how product families are created and configured. This is particularly useful in systems where product configurations might be complex and need to be precisely managed to ensure system stability.

Better Support for Testing and Mocking

The use of abstract factories makes it easier to test applications because you can create mock objects that follow the same interfaces as the products created by the actual factories. This facilitates testing environments where real objects can be replaced with stubs or mocks, improving test reliability and execution speed.

In practice, these benefits lead to a more robust, maintainable, and flexible system architecture. Abstract Factory is especially beneficial in large-scale projects, where managing the complexity and maintaining consistency across various parts of the system are paramount.

How to implement Abstract Factory Pattern (in Java)

Without using Abstract factory pattern:

  1. High Coupling:: The application directly instantiates specific component classes based on the operating system. This results in high coupling between the client code and the concrete implementations of the components. Every time a new component or a new operating system support is added, the main application logic must be altered.
  2. Limited Flexibility: The application must be aware of the differences among various implementations (e.g., WindowsButton, LinuxButton). Adding a new type of component or supporting a new operating system requires changes to the core logic, reducing flexibility and increasing the complexity of updates.
  3. Poor Scalability: As the number of component types and supported operating systems grows, the initial approach’s complexity and maintenance burden escalate. Scaling up involves adding more conditional branches and extending the client code to handle new cases, which is error-prone and inefficient.
  4. Difficult Maintenance: Maintenance becomes cumbersome as any changes to the component creation logic might require modifications scattered across multiple places within the client code. This is especially challenging when similar changes need to be replicated across various parts of the application.
  5. Lack of Encapsulation: Creation details of UI components are exposed to and managed by the client, which goes against the encapsulation principle. The client code not only handles its primary responsibilities but also manages component instantiation specifics.
  6. Inflexibility in Testing: Testing such an application can be difficult because it’s hard to isolate the component creation logic from the usage logic, making unit testing more challenging. Mocking or replacing component implementations requires significant effort due to the tight coupling.

Here is the code implementation

interface Button {
    void paint();
}

interface TextBox {
    void render();
}

class WindowsButton implements Button {
    @Override
    public void paint() {
        System.out.println("Rendering a button in a Windows style.");
    }
}

class LinuxButton implements Button {
    @Override
    public void paint() {
        System.out.println("Rendering a button in a Linux style.");
    }
}

class MacOSButton implements Button {
    @Override
    public void paint() {
        System.out.println("Rendering a button in a MacOS style.");
    }
}

class WindowsTextBox implements TextBox {
    @Override
    public void render() {
        System.out.println("Displaying a textbox in a Windows style.");
    }
}

class LinuxTextBox implements TextBox {
    @Override
    public void render() {
        System.out.println("Displaying a textbox in a Linux style.");
    }
}

class MacOSTextBox implements TextBox {
    @Override
    public void render() {
        System.out.println("Displaying a textbox in a MacOS style.");
    }
}

public class Application {
    public static void main(String[] args) {
        String osName = System.getProperty("os.name");
        Button button;
        TextBox textBox;

        if (osName.contains("Windows")) {
            button = new WindowsButton();
            textBox = new WindowsTextBox();
        } else if (osName.contains("Linux")) {
            button = new LinuxButton();
            textBox = new LinuxTextBox();
        } else if (osName.contains("Mac")) {
            button = new MacOSButton();
            textBox = new MacOSTextBox();
        } else {
            throw new RuntimeException("Unsupported operating system");
        }

        button.paint();
        textBox.render();
    }
}

Using abstract factory pattern:

  1. Low Coupling: The Abstract Factory pattern reduces the coupling between the application and the concrete implementations of components. The client code deals only with interfaces, not specific classes, thus adhering to the dependency inversion principle.
  2. Enhanced Flexibility: The pattern allows the application to support different product families and configurations without changes to the client code. New types of components or new operating system support can be added by simply creating new factories and products that implement the predefined interfaces.
  3. Improved Scalability: Adding new families of products becomes straightforward. Developers can introduce new factories to handle new sets of interrelated products without altering existing client logic, which supports better scalability.
  4. Simplified Maintenance: Since product creation is centralized in specific factory classes, any changes to the creation logic are isolated from the rest of the application. This encapsulation makes the system easier to maintain and extend.
  5. Better Encapsulation: The Abstract Factory pattern encapsulates the creation details of the components, keeping the client code clean and focused on its primary responsibilities. This separation of concerns leads to cleaner, more organized code.
  6. Easier Testing and Mocking: The use of interfaces and separation of creation logic allows for easier testing and mocking. Factories can be easily swapped with mock factories in test environments, facilitating unit testing and improving test coverage without dealing with concrete component instances.

Here is the code:

interface Button {
    void paint();
}

interface TextBox {
    void render();
}

interface GUIFactory {
    Button createButton();
    TextBox createTextBox();
}

class WindowsButton implements Button {
    @Override
    public void paint() {
        System.out.println("Rendering a button in a Windows style.");
    }
}

class LinuxButton implements Button {
    @Override
    public void paint() {
        System.out.println("Rendering a button in a Linux style.");
    }
}

class MacOSButton implements Button {
    @Override
    public void paint() {
        System.out.println("Rendering a button in a MacOS style.");
    }
}

class WindowsTextBox implements TextBox {
    @Override
    public void render() {
        System.out.println("Displaying a textbox in a Windows style.");
    }
}

class LinuxTextBox implements TextBox {
    @Override
    public void render() {
        System.out.println("Displaying a textbox in a Linux style.");
    }
}

class MacOSTextBox implements TextBox {
    @Override
    public void render() {
        System.out.println("Displaying a textbox in a MacOS style.");
    }
}

class WindowsFactory implements GUIFactory {
    @Override
    public Button createButton() {
        return new WindowsButton();
    }
    
    @Override
    public TextBox createTextBox() {
        return new WindowsTextBox();
    }
}

class LinuxFactory implements GUIFactory {
    @Override
    public Button createButton() {
        return new LinuxButton();
    }
    
    @Override
    public TextBox createTextBox() {
        return new LinuxTextBox();
    }
}

class MacOSFactory implements GUIFactory {
    @Override
    public Button createButton() {
        return new MacOSButton();
    }
    
    @Override
    public TextBox createTextBox() {
        return new MacOSTextBox();
    }
}

public class Application {
    private Button button;
    private TextBox textBox;

    public Application(GUIFactory factory) {
        button = factory.createButton();
        textBox = factory.createTextBox();
    }

    public void display() {
        button.paint();
        textBox.render();
    }

    public static void main(String[] args) {
        String osName = System.getProperty("os.name");
        GUIFactory factory;

        if (osName.contains("Windows")) {
            factory = new WindowsFactory();
        } else if (osName.contains("Linux")) {
            factory = new LinuxFactory();
        } else if (osName.contains("Mac")) {
            factory = new MacOSFactory();
        } else {
            throw new RuntimeException("Unsupported operating system");
        }

        Application app = new Application(factory);
        app.display();
    }
}
See more