Erdem's Second Brain

Abstract Factory

Oct 11, 20248 min read

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 used when the system needs to create multiple families of related products but wants to ensure that the product families remain consistent.

Key Points:

  1. Abstract Factory: Declares an interface for creating abstract products (related objects).
  2. Concrete Factory: Implements the operations to create concrete product objects.
  3. Abstract Products: Declare interfaces for a set of products that are related.
  4. Concrete Products: Implement the specific product interfaces.
  5. Client: Uses only the interfaces declared by the abstract factory and abstract products. It doesn’t need to know about the concrete products.

Structure of the Abstract Factory Pattern:

  • AbstractFactory: Declares a set of creation methods for the abstract products.
  • ConcreteFactory: Implements the creation methods for specific products.
  • AbstractProduct: Declares an interface for a type of product.
  • ConcreteProduct: Implements the abstract product interface.
  • Client: Interacts with the factory to create objects using the abstract interface.

Example Scenario:

Imagine you’re building a UI toolkit that can create both MacOS and Windows GUI elements like buttons and checkboxes. You want a consistent look for each platform, so you’ll use an Abstract Factory pattern.

Step-by-Step Example:

1. Abstract Factory (GUIFactory):

This factory defines methods for creating the abstract products (Button and Checkbox).

from abc import ABC, abstractmethod
 
# Abstract Factory
class GUIFactory(ABC):
    @abstractmethod
    def create_button(self):
        pass
    
    @abstractmethod
    def create_checkbox(self):
        pass

2. Abstract Products (Button and Checkbox):

These are the abstract products that will be implemented by concrete classes.

# Abstract Product A (Button)
class Button(ABC):
    @abstractmethod
    def paint(self):
        pass
 
# Abstract Product B (Checkbox)
class Checkbox(ABC):
    @abstractmethod
    def paint(self):
        pass

3. Concrete Products:

These implement the interfaces of the abstract products for specific platforms (Windows and MacOS).

# Concrete Product A1 (Windows Button)
class WindowsButton(Button):
    def paint(self):
        print("Rendering a button in Windows style.")
 
# Concrete Product B1 (Windows Checkbox)
class WindowsCheckbox(Checkbox):
    def paint(self):
        print("Rendering a checkbox in Windows style.")
 
# Concrete Product A2 (Mac Button)
class MacButton(Button):
    def paint(self):
        print("Rendering a button in MacOS style.")
 
# Concrete Product B2 (Mac Checkbox)
class MacCheckbox(Checkbox):
    def paint(self):
        print("Rendering a checkbox in MacOS style.")

4. Concrete Factories:

These implement the creation methods for the specific products.

# Concrete Factory 1 (Windows Factory)
class WindowsFactory(GUIFactory):
    def create_button(self):
        return WindowsButton()
 
    def create_checkbox(self):
        return WindowsCheckbox()
 
# Concrete Factory 2 (Mac Factory)
class MacFactory(GUIFactory):
    def create_button(self):
        return MacButton()
 
    def create_checkbox(self):
        return MacCheckbox()

5. Client:

The client works with the factories through the abstract interface, so it can easily switch between different product families (Windows or MacOS) without modifying its code.

# Client code
class Application:
    def __init__(self, factory: GUIFactory):
        self.factory = factory
        self.button = None
        self.checkbox = None
 
    def create_ui(self):
        self.button = self.factory.create_button()
        self.checkbox = self.factory.create_checkbox()
 
    def paint_ui(self):
        self.button.paint()
        self.checkbox.paint()
 
# Usage
def get_factory(os_type):
    if os_type == "Windows":
        return WindowsFactory()
    elif os_type == "Mac":
        return MacFactory()
    else:
        raise ValueError("Unknown operating system.")
 
# Example usage:
if __name__ == "__main__":
    # Example for Windows GUI
    windows_factory = get_factory("Windows")
    app = Application(windows_factory)
    app.create_ui()
    app.paint_ui()
    
    print("------")
    
    # Example for MacOS GUI
    mac_factory = get_factory("Mac")
    app = Application(mac_factory)
    app.create_ui()
    app.paint_ui()

Output:

Rendering a button in Windows style.
Rendering a checkbox in Windows style.
------
Rendering a button in MacOS style.
Rendering a checkbox in MacOS style.

Explanation:

  • The Abstract Factory (GUIFactory) defines the methods for creating abstract products (Button, Checkbox).
  • Each Concrete Factory (WindowsFactory, MacFactory) implements those methods and creates products specific to the platform.
  • The Client (Application) doesn’t care about which specific factory or products it is using. It works only with the abstract interfaces.

Benefits of Abstract Factory Pattern:

  1. Encapsulation of Object Creation: The factory encapsulates the object creation process, so clients do not need to know about the specific classes used.
  2. Consistency: Ensures that products from the same family are compatible with each other.
  3. Scalability: You can easily add new factories (e.g., LinuxFactory) without modifying the existing code.

This design pattern is useful in scenarios where you need to create objects that belong to families or groups and need to ensure they work well together.

When to use it ?

The Abstract Factory Pattern is useful when:

  • If your system needs to create multiple related objects that must work together, you should use the Abstract Factory pattern. For example, creating a UI toolkit that has consistent components (buttons, text fields, checkboxes) for different platforms (Windows, MacOS, Linux).
  • Example: In a game, you might need to create different types of creatures and terrain based on the level (e.g., Forest creatures vs. Desert creatures). Each level would be a family of related objects (forest creatures and forest terrain).

2. You want to ensure consistency among objects:

  • Abstract Factory helps ensure that objects from a single family are used together. It enforces a consistent look or behavior. For example, if you are creating Windows-style buttons and checkboxes, you don’t accidentally mix them with Mac-style buttons.
  • Example: When designing a graphical user interface for an application, using the Abstract Factory can ensure that all components (buttons, dialogs, scroll bars) follow the same platform-specific look and feel.

3. You want to decouple object creation from client code:

  • The pattern hides the details of how products are created. The client code interacts only with interfaces, making it flexible and open to extension. The client doesn’t need to know which concrete class is being used; it only depends on the abstract factory and abstract product interfaces.
  • Example: In a software system where you want to switch between different databases (e.g., MySQL, PostgreSQL) without changing the core business logic, an Abstract Factory could help in switching between different database families (by providing factory methods to create connections, queries, etc.).

4. You need to switch between product families dynamically:

  • If you need to be able to switch between different product families (e.g., between MacOS and Windows GUIs) dynamically at runtime without changing your code, Abstract Factory allows you to do this easily. The factory object can be passed to the client, and the client will start producing objects from the selected family without knowing which one was chosen.
  • Example: If you are developing software that needs to work on multiple operating systems, the Abstract Factory allows you to swap between different UI elements for Windows, MacOS, or Linux at runtime.

5. The system should be open to extension but closed for modification:

  • According to the Open/Closed Principle (OCP), classes should be open for extension but closed for modification. With Abstract Factory, you can introduce new product families without changing the existing code. You just create new factories and product implementations.
  • Example: Adding a new “LinuxFactory” for a new operating system doesn’t require changing the existing WindowsFactory or MacFactory. You just create the new factory and integrate it without touching other parts of the code.

When NOT to use Abstract Factory:

  • Simple object creation: If you only need to create a few objects and don’t require a consistent family of related objects, using the Abstract Factory pattern can over-complicate your code. In such cases, simpler patterns like Factory Method or even just a regular constructor might be sufficient.

  • Too many families: If you need too many product families and they don’t need to be consistent, the pattern may introduce unnecessary complexity. In such scenarios, you may want to reconsider if this pattern is the best fit.

Example Scenarios:

  1. Cross-platform software:

    • If you’re developing software that must run on different operating systems (like Windows, Mac, Linux), you can use the Abstract Factory to create platform-specific UI elements. Each OS would have its own factory to create buttons, scrollbars, and windows.

  2. Database drivers:

    • If your software supports multiple databases (e.g., MySQL, PostgreSQL), each database could be a product family, with different drivers, connections, and queries implemented for each type. The Abstract Factory ensures that the correct set of database objects is used depending on the selected database.

  3. Theming in web or mobile apps:

    • If you’re developing an app with different themes (e.g., light mode, dark mode), each theme could have its own factory for generating UI components with the correct colors, fonts, and styles.

  4. Game development:

    • In a game, if you have different environments or levels (e.g., forest level, desert level), each environment may have a different set of objects (trees, rocks, creatures) that need to be created. The Abstract Factory can ensure that objects created for a specific level are consistent with the environment.

In summary, you should use the Abstract Factory pattern when:

  • You need to create families of related or dependent objects.
  • You want to ensure that related objects are used together consistently.
  • You want to isolate the client from the details of object creation.
  • You anticipate the need to introduce new families of products in the future without changing existing code.

Graph View

Backlinks

  • No backlinks found