Patterns: Abstract Factory

Published: 01/03/25 by stsykalovskyi

Patterns: Abstract Factory

Pattern Name
Abstract Factory

Description:
The Abstract Factory pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes. It allows the creation of related objects in a way that avoids tight coupling between the client and the concrete classes.

Category
Creational

Problem Statement
Context:
In a system that requires the creation of multiple related objects, managing different types of objects in a way that they are compatible can be challenging. If the creation of these objects is done directly in the client code, it leads to tight coupling, making the system difficult to maintain and extend.

Example:
Imagine an application that works across multiple operating systems (e.g., Windows, macOS, Linux). Each operating system requires different UI components such as buttons, menus, or text fields, but they should follow the same interface to ensure consistent interaction.

Solution
Concept:
The Abstract Factory pattern addresses this problem by defining an interface for creating families of related objects. Concrete factories implement this interface and create specific instances of these objects. The client code interacts with the abstract factory interface, ensuring that it works with the appropriate objects without knowing their exact types.

Diagram:

+-------------------+         +-------------------+  
| AbstractFactory   |<>-------| ConcreteFactory   |  
+-------------------+         +-------------------+  
| createProductA()  |         | createProductA()   |  
| createProductB()  |         | createProductB()   |  
+-------------------+         +-------------------+  
          ^                            ^  
          |                            |  
+-------------------+         +-------------------+  
| AbstractProductA  |<>-------| ConcreteProductA  |  
+-------------------+         +-------------------+  
| doSomething()     |         | doSomething()      |  
+-------------------+         +-------------------+  
          ^                            ^  
          |                            |  
+-------------------+         +-------------------+  
| AbstractProductB  |<>-------| ConcreteProductB  |  
+-------------------+         +-------------------+  
| doSomethingElse() |         | doSomethingElse()  |  
+-------------------+         +-------------------+


Implementation

# Abstract Factory
class GUIFactory:
    def create_button(self):
        pass
    
    def create_textfield(self):
        pass

# Concrete Factory for Windows
class WindowsFactory(GUIFactory):
    def create_button(self):
        return WindowsButton()

    def create_textfield(self):
        return WindowsTextField()

# Concrete Factory for macOS
class MacFactory(GUIFactory):
    def create_button(self):
        return MacButton()

    def create_textfield(self):
        return MacTextField()

# Abstract Products
class Button:
    def click(self):
        pass

class TextField:
    def type_text(self):
        pass

# Concrete Products for Windows
class WindowsButton(Button):
    def click(self):
        return "Windows Button Clicked"

class WindowsTextField(TextField):
    def type_text(self):
        return "Text typed in Windows TextField"

# Concrete Products for macOS
class MacButton(Button):
    def click(self):
        return "Mac Button Clicked"

class MacTextField(TextField):
    def type_text(self):
        return "Text typed in Mac TextField"

# Client Code
def client_code(factory: GUIFactory):
    button = factory.create_button()
    textfield = factory.create_textfield()
    print(button.click())
    print(textfield.type_text())

# Use a specific factory
windows_factory = WindowsFactory()
client_code(windows_factory)

mac_factory = MacFactory()
client_code(mac_factory)

Participants

  • AbstractFactory: Declares the creation methods for abstract products.
  • ConcreteFactory: Implements the creation methods, instantiating concrete product objects.
  • AbstractProduct: Declares the interface for a type of product (e.g., Button, TextField).
  • ConcreteProduct: Implements the abstract product interface for specific types (e.g., WindowsButton, MacTextField).
  • Client: Uses the abstract factory and products, relying on the factory interface rather than concrete classes.

Advantages

  • Code Reusability: The client code works with abstract products and factories, promoting reuse of components.
  • Scalability: New product families can be introduced without modifying client code, supporting easier extension.
  • Maintainability: Reduces dependency on specific product implementations, making maintenance easier when switching between different families of products.

Drawbacks

  • Complexity: The pattern introduces additional classes and interfaces, which can increase the complexity of the system.
  • Rigid Structure: If not used properly, the pattern can lead to unnecessary complexity when only a single product family is needed.

Use Cases

  • Creating UI components for different platforms (Windows, macOS, Linux).
  • Developing cross-platform applications that need to work with multiple families of related objects.
  • Designing systems that require different themes or styles based on context (e.g., different look-and-feel for different types of users).

Related Patterns

  • Factory Method: The Factory Method pattern focuses on creating individual products, while the Abstract Factory pattern creates families of related products.
  • Builder: The Builder pattern is used when the creation process of the product is complex, whereas Abstract Factory deals with families of related objects.

Category: Programming

Tags: patterns