Introduction

Design patterns are essential tools in software development, providing reusable solutions to common problems. In this article, we’ll explore improved implementations of two fundamental design patterns: the Factory pattern and the Observer pattern. We’ll focus on enhancements that leverage Python’s features to create more robust, readable, and maintainable code.

Prerequisites

• Python 3.7 or later installed on your system

Building a Better Factory Pattern in Python

The Factory pattern is a creational design pattern that provides an interface for creating objects without specifying their exact classes. It’s particularly useful when:

• The exact type of object needed isn’t known until runtime
• You want to delegate responsibility for object creation to specialized factory classes
• You need to encapsulate the creation logic to maintain a clean separation of concerns

Let’s build an improved Factory implementation step by step.

Step 1: Define the Product Interface

First, we need a common interface for all products our factory will create:

# Add this code to factory_pattern_example.py
from abc import ABC, abstractmethod
from typing import Dict, Type

class Product(ABC):
    @abstractmethod
    def operation(self) -> str:
        """
        The Product interface declares operations that all concrete products must implement.
        """
        pass

Why this approach?

• Using an Abstract Base Class (ABC) provides a clear contract that subclasses must follow
• The @abstractmethod decorator enforces implementation of the method in concrete classes
• Type annotations make the expected return value explicit
• The docstring clearly explains the purpose of the method

Step 2: Create Concrete Product Classes

Now we can implement concrete product classes that will be instantiated by our factory:

# Add this code to factory_pattern_example.py
class ConcreteProduct1(Product):
    def operation(self) -> str:
        return "Result of ConcreteProduct1"

class ConcreteProduct2(Product):
    def operation(self) -> str:
        return "Result of ConcreteProduct2"

Why this matters:

• Each concrete product implements the same interface, ensuring consistent behavior
• Client code can work with any product through the common interface
• New product types can be added without changing client code
• Each product can provide its own specialized implementation of the operation

Step 3: Implement the Factory

Next, we’ll create our improved factory with a registration system:

# Add this code to factory_pattern_example.py
class Factory:
    _creators: Dict[str, Type[Product]] = {
        "product1": ConcreteProduct1,
        "product2": ConcreteProduct2
    }

    @classmethod
    def create_product(cls, product_type: str) -> Product:
        creator = cls._creators.get(product_type)
        if not creator:
            raise ValueError(f"Invalid product type: {product_type}")
        return creator()

Key benefits:

• Class-level dictionary: Centralizes all product mappings in one place
• Type annotations: Documents that the dictionary maps strings to Product classes
• Class method approach: Makes the factory usable without instantiation
• Dictionary lookup: More efficient than a series of if/elif statements
• Error handling: Provides clear feedback when an invalid type is requested
• Single responsibility: The factory’s sole responsibility is creating the right objects

Step 4: Extending with Factory Method Pattern

For cases where you need more complex creation logic, we can implement the Factory Method pattern:

# Add this code to factory_pattern_example.py
class Creator(ABC):
    @abstractmethod
    def factory_method(self) -> Product:
        """
        Subclasses must implement this method to create a specific Product.
        """
        pass
    
    def some_operation(self) -> str:
        """
        Core business logic that relies on products created by the factory method.
        """
        product = self.factory_method()
        result = f"Creator worked with {product.operation()}"
        return result

class ConcreteCreator1(Creator):
    def factory_method(self) -> Product:
        return ConcreteProduct1()

When and why to use this approach:

• When creation logic needs to vary by subclass
• To separate product creation from the business logic that uses the products
• To allow subclasses to alter the type of objects that will be created
• When you want to reuse existing code but customize the products it creates

Step 5: Using the Factory

Here’s how to use our factory implementations:

# Add this code to factory_pattern_example.py
if __name__ == "__main__":
    # Using our Factory implementation
    product1 = Factory.create_product("product1")
    print(product1.operation())  # Output: Result of ConcreteProduct1

    product2 = Factory.create_product("product2")
    print(product2.operation())  # Output: Result of ConcreteProduct2

    try:
        Factory.create_product("invalid_product")
    except ValueError as e:
        print(e)  # Output: Invalid product type: invalid_product

    # Using the Factory Method variant
    creator1 = ConcreteCreator1()
    result = creator1.some_operation()
    print(result)  # Output: Creator worked with Result of ConcreteProduct1

Benefits demonstrated:

• Client code works with products solely through their interfaces
• Error handling demonstrates robust behavior when invalid inputs are provided
• The Factory Method pattern shows how business logic can be separated from product creation
• The code is clean, readable, and maintainable

Advanced Factory Pattern Techniques

1. Registering Products Dynamically

This technique allows new product types to be added at runtime:

# Add this code to factory_pattern_example.py
class DynamicFactory:
    _creators = {}
    
    @classmethod
    def register(cls, product_type: str, creator: Type[Product]) -> None:
        cls._creators[product_type] = creator
        
    @classmethod
    def create_product(cls, product_type: str) -> Product:
        creator = cls._creators.get(product_type)
        if not creator:
            raise ValueError(f"Invalid product type: {product_type}")
        return creator()

# Usage example for DynamicFactory
if __name__ == "__main__":
    print("\n=== Dynamic Factory Example ===")
    DynamicFactory.register("product3", ConcreteProduct1)
    product = DynamicFactory.create_product("product3")
    print(product.operation())  # Output: Result of ConcreteProduct1

When to use dynamic registration:

• When available product types aren’t known at compile time
• For plugin architectures where new products can be added by third parties
• When product types need to be configured at runtime based on external settings
• To support A/B testing different product implementations

2. Using Decorators for Registration

Decorators provide an elegant way to register products:

# Add this code to factory_pattern_example.py
class DecoratorFactory:
    _creators = {}
    
    @classmethod
    def register(cls, product_type: str):
        def decorator(creator):
            cls._creators[product_type] = creator
            return creator
        return decorator
        
    @classmethod
    def create_product(cls, product_type: str) -> Product:
        creator = cls._creators.get(product_type)
        if not creator:
            raise ValueError(f"Invalid product type: {product_type}")
        return creator()

# Usage example for DecoratorFactory
@DecoratorFactory.register("product4")
class ConcreteProduct4(Product):
    def operation(self) -> str:
        return "Result of ConcreteProduct4"

if __name__ == "__main__":
    print("\n=== Decorator Factory Example ===")
    product = DecoratorFactory.create_product("product4")
    print(product.operation())  # Output: Result of ConcreteProduct4

Benefits of decorator registration:

• Classes self-register with the factory
• Registration happens at class definition time
• The relationship between the product and its identifier is visually clear
• Reduces the chance of registration errors by keeping registration close to class definition

Building a Better Observer Pattern in Python

The Observer pattern allows objects (observers) to be notified when the state of another object (subject) changes. This pattern is ideal for:

• Implementing event handling systems
• Building reactive programming models
• Creating distributed systems where components need to stay in sync
• Developing user interfaces that respond to data changes

Let’s create a new file called observer_pattern_example.py for our Observer pattern implementation.

Step 1: Define the Observer Interface

First, we need to define the interface that all observers will implement:

# Add this code to observer_pattern_example.py
from abc import ABC, abstractmethod
from typing import List

class Observer(ABC):
    @abstractmethod
    def update(self, message: str) -> None:
        """
        Receive update notifications from subjects.
        """
        pass

Why define this interface:

• Establishes a clear contract for all observer classes
• Subjects can work with any observer implementing this interface
• The abstract method ensures all concrete observers must implement the update method
• Type hints provide clarity on expected parameter types

Step 2: Define the Subject Interface

Next, we create the interface for subjects that observers will watch:

# Add this code to observer_pattern_example.py
class Subject(ABC):
    @abstractmethod
    def attach(self, observer: Observer) -> None:
        """
        Attach an observer to the subject.
        """
        pass

    @abstractmethod
    def detach(self, observer: Observer) -> None:
        """
        Detach an observer from the subject.
        """
        pass

    @abstractmethod
    def notify(self) -> None:
        """
        Notify all observers about an event.
        """
        pass

Design considerations:

• Clear separation between attaching, detaching, and notification logic
• Type annotations establish the relationship between Observer and Subject
• The interface defines the minimum functionality required for the pattern
• By using an ABC, we ensure all subjects must implement these operations

Step 3: Implement the Concrete Subject

Now we implement a concrete subject class that maintains a list of observers and notifies them of changes:

# Add this code to observer_pattern_example.py
class ConcreteSubject(Subject):
    def __init__(self):
        self._observers: List[Observer] = []
        self._state: str = ""

    def attach(self, observer: Observer) -> None:
        self._observers.append(observer)

    def detach(self, observer: Observer) -> None:
        try:
            self._observers.remove(observer)
        except ValueError:
            print(f"Warning: Observer {observer} not found in the list.")

    def notify(self) -> None:

[observer.update(self._state) for observer in self._observers]

def set_state(self, state: str) -> None: self._state = state self.notify()

Key improvements in this implementation:

• Type hints: Clearly documents that _observers is a list of Observer instances
• Error handling: Gracefully handles removal of non-existent observers
• Automatic notification: State changes automatically trigger notifications
• List comprehension: Uses Python’s efficient list comprehension for notification
• Proper encapsulation: Uses leading underscore for internal attributes

Step 4: Implement the Concrete Observer

Now we need to create concrete observers that will react to notifications:

# Add this code to observer_pattern_example.py
class ConcreteObserver(Observer):
    def __init__(self, name: str):
        self.name = name

    def update(self, message: str) -> None:
        print(f"{self.name} received message: {message}")

Implementation benefits:

• Simple and focused implementation of the abstract interface
• Each observer has a unique identifier (name) for debugging and logging
• The update logic is clear and performs a specific action
• The responsibility of reacting to changes is encapsulated within each observer

Step 5: Using the Observer Pattern

Here’s how to use our observer implementation:

# Add this code to observer_pattern_example.py
if __name__ == "__main__":
    subject = ConcreteSubject()

    observer1 = ConcreteObserver("Observer 1")
    observer2 = ConcreteObserver("Observer 2")

    subject.attach(observer1)
    subject.attach(observer2)

    subject.set_state("New State")
    # Output:
    # Observer 1 received message: New State
    # Observer 2 received message: New State

    subject.detach(observer1)
    subject.set_state("Another State")
    # Output:
    # Observer 2 received message: Another State

    # Attempting to detach an observer that's not in the list
    subject.detach(observer1)
    # Output:
    # Warning: Observer <__main__.ConcreteObserver object at ...> not found in the list.

Usage scenario highlights:

• Multiple observers can be attached to a single subject
• When the subject’s state changes, all observers are notified automatically
• Observers can be dynamically added or removed at runtime
• Error handling ensures robust operation even with invalid detach operations
• The pattern maintains a clean separation between the subject and its observers

Advanced Observer Pattern Techniques

1. Filtered Notifications

This technique allows observers to selectively respond to notifications:

# Add this code to observer_pattern_example.py
class FilteredObserver(Observer):
    def __init__(self, name: str, filter_condition):
        self.name = name
        self.filter_condition = filter_condition
    
    def update(self, message: str) -> None:
        if self.filter_condition(message):
            print(f"{self.name} received filtered message: {message}")

# Usage example for FilteredObserver
if __name__ == "__main__":
    print("\n=== Filtered Observer Example ===")
    subject = ConcreteSubject()
    
    # Only respond to messages containing "important"
    important_filter = lambda msg: "important" in msg.lower()
    filtered_observer = FilteredObserver("Priority Observer", important_filter)
    subject.attach(filtered_observer)
    
    subject.set_state("This is an important update")  # Observer will respond
    subject.set_state("Routine update")  # Observer will ignore

When and why to use filtered observers:

• To reduce unnecessary processing when only specific changes matter
• For implementing priority-based notification systems
• To create specialized observers that focus on particular events
• When observers need different criteria for when they should act

2. Push vs Pull Notifications

The pull model gives observers more control over what data they retrieve:

# Add this code to observer_pattern_example.py
class PullSubject(Subject):
    def __init__(self):
        self._observers: List[Observer] = []
        self._state: str = ""
        self._timestamp: int = 0
    
    def attach(self, observer: Observer) -> None:
        self._observers.append(observer)
    
    def detach(self, observer: Observer) -> None:
        try:
            self._observers.remove(observer)
        except ValueError:
            print(f"Warning: Observer {observer} not found in the list.")
    
    def notify(self) -> None:
        # Only notify observers that something changed

[observer.update_available(self) for observer in self._observers]

def get_state(self) -> str: return self._state def get_timestamp(self) -> int: return self._timestamp def set_state(self, state: str) -> None: self._state = state self._timestamp += 1 self.notify() class PullObserver(ABC): @abstractmethod def update_available(self, subject: PullSubject) -> None: pass class ConcretePullObserver(PullObserver): def __init__(self, name: str): self.name = name self.last_update = 0 def update_available(self, subject: PullSubject) -> None: if subject.get_timestamp() > self.last_update: self.last_update = subject.get_timestamp() state = subject.get_state() print(f”{self.name} pulled update: {state}”) # Usage example for Pull notification model if __name__ == “__main__”: print(“\n=== Pull Observer Example ===”) pull_subject = PullSubject() pull_observer = ConcretePullObserver(“Pull Observer”) pull_subject.attach(pull_observer) pull_subject.set_state(“First pull state”) pull_subject.set_state(“Second pull state”)

Benefits of the pull approach:

• Efficiency: Observers retrieve only the data they need
• Control: Observers decide when and what to retrieve
• Reduced coupling: Subject doesn’t need to know what data observers require
• Change tracking: Observers can detect which data has changed since their last update
• Conditional updates: Observers can implement logic to decide if an update is needed

Real-World Applications

Factory Pattern in Action

1. Database Connections: Factory methods create the appropriate database connection based on configuration settings:
2. UI Elements: In GUI applications, factories create themed interface components:
3. Plugin Systems: Dynamically loading modules or plugins:
4. Configuration-Driven Development: Creating objects based on configuration files:

Observer Pattern in Practice

1. Event Handling Systems: UI frameworks use observers to handle user interactions:
2. Logging and Monitoring: Observers collect and process application events:
3. Data Binding: Keeping UI elements synchronized with data models:
4. Distributed Systems: Propagating state changes across system components:

Comparing Factory and Observer Patterns

While these patterns solve different problems, they’re often used together in complex applications:

Benefits of These Implementations

1. Type Hinting:
   • Improves code readability and maintainability
   • Enhances IDE support for better autocomplete and error detection
   • Helps catch type-related errors during development
   • Documents relationships between classes more explicitly
2. Improved Error Handling:
   • The detach method now handles the case when an observer is not in the list
   • Provides a warning message instead of raising an exception
   • Ensures the application continues to function even when errors occur
   • Makes debugging easier by providing clear error messages
3. Efficient Notification:
   • Uses a list comprehension for notifying observers
   • More Pythonic and potentially more efficient than traditional loops
   • Reduces code complexity and improves readability
   • Scales well with larger numbers of observers
4. Clear Method Signatures:
   • The update method clearly specifies that it takes a string message
   • The set_state method indicates it takes a string state
   • Makes the contract between components explicit
   • Reduces the chance of parameter passing errors

When Not to Use These Patterns

Factory Pattern Drawbacks

• Overcomplicated for Simple Cases: If you’re only creating a few simple objects, direct instantiation might be clearer
• Increased Complexity: Adds additional classes and indirection that may not be necessary for small applications
• Testing Challenges: Factory methods may be harder to mock in tests than direct construction

Observer Pattern Drawbacks

• Memory Leaks: If observers aren’t properly detached, they can cause memory leaks
• Debugging Difficulties: With many observers, it can be harder to trace execution flow
• Performance Overhead: Notification of many observers can cause performance issues
• Unexpected Side Effects: Changes can cascade through the system in unexpected ways

Summary

In this article, we’ve explored improved implementations of two fundamental design patterns: Factory and Observer. By leveraging Python’s modern features like type hints, abstract base classes, and efficient error handling, we’ve created implementations that are more robust, maintainable, and easier to understand than traditional approaches.

The Factory pattern provides an elegant way to decouple object creation from usage, allowing systems to be more flexible and adaptable to change. Our implementation demonstrated:

• Type-safe interfaces using abstract base classes
• Multiple factory variants including basic, dynamic registration, and decorator-based approaches
• Clear error handling to improve debugging and reliability
• Pythonic code style that aligns with modern best practices

The Observer pattern establishes a one-to-many dependency between objects, enabling automatic notification of state changes. Our implementation showcased:

• Clear separation between subjects and observers through well-defined interfaces
• Improved error handling for detaching non-existent observers
• More efficient notification using list comprehensions
• Advanced techniques like filtered notifications and pull-based updates

Both patterns serve different purposes but share common benefits in our improved implementations:

1. Better code organization through clear interfaces and proper encapsulation
2. Enhanced type safety with Python’s type hints
3. Graceful error handling for more robust applications
4. Cleaner, more maintainable code that’s easier to extend