Chapter 14: Design Patterns in the Pythonic World

The concept of "design patterns" was popularized by the book Design Patterns: Elements of Reusable Object-Oriented Software, written by the "Gang of Four" (GoF). These patterns provide proven, reusable solutions to common problems within a given software design context. They are templates for how to structure code to solve a general problem, not finished algorithms.

For a senior developer, knowing these patterns is crucial. However, it's even more crucial to recognize that many classic patterns, originally conceived for statically-typed languages like C++ and Java, are often implemented differently—or are entirely unnecessary—in a dynamic language like Python. Python's first-class functions, decorators, and flexible object model provide more direct and elegant solutions to problems that require complex class hierarchies in other languages.

This chapter explores several key design patterns and examines them through a Pythonic lens.

This chapter covers:

1. Creational Patterns: The Singleton and Factory patterns.

2. Structural Patterns: The Decorator and Adapter patterns.

3. Behavioral Patterns: The Strategy and Observer patterns.

4. How Python's features offer unique implementations for these patterns.

Creational Patterns

These patterns deal with object creation mechanisms, trying to create objects in a manner suitable to the situation.

1. The Singleton Pattern

Intent: Ensure a class only has one instance, and provide a global point of access to it. Classic Implementation: In Java, this often involves a private constructor and a static getInstance() method. Pythonic Implementation: The simplest and most common approach is to use a module. Since modules in Python are cached on first import, they are singletons by nature.

# config.py - A module-based singleton
# This module will be initialized only once.

_api_key = None
_timeout = 5

def configure(api_key, timeout=10):
    global _api_key, _timeout
    _api_key = api_key
    _timeout = timeout

def get_session():
    if not _api_key:
        raise ValueError("API Key has not been configured.")
    # Imagine a session object is created here using the config
    return f"Session created with API Key: {_api_key[:4]}... and timeout: {_timeout}"

# --- main.py ---
# import config
#
# config.configure(api_key="ABC-123")
# session1 = config.get_session()
# print(session1)
#
# # Elsewhere in the application...
# import config
# session2 = config.get_session() # Will use the same configuration
# print(session2)

This is clean, simple, and avoids the need for complex class-based logic.

2. The Factory Pattern

Intent: Define an interface for creating an object, but let subclasses decide which class to instantiate. Classic Implementation: A creator class with an abstract factory method. Pythonic Implementation: A simple function often suffices. First-class functions allow you to pass the type you want to create as an argument, making complex hierarchies unnecessary.

# A simple factory function
class JSONSerializer:
    def serialize(self, data):
        return f"<json>{data}</json>"

class XMLSerializer:
    def serialize(self, data):
        return f"<xml>{data}</xml>"

def serializer_factory(format_type):
    """A factory function that returns a serializer class."""
    serializers = {
        'json': JSONSerializer,
        'xml': XMLSerializer
    }
    return serializers[format_type]()

# Usage
json_s = serializer_factory('json')
print(json_s.serialize("My Data")) # Output: <json>My Data</json>

xml_s = serializer_factory('xml')
print(xml_s.serialize("My Data"))  # Output: <xml>My Data</xml>

Structural Patterns

These patterns concern class and object composition.

3. The Decorator Pattern

Intent: Attach additional responsibilities to an object dynamically. Classic Implementation: A "wrapper" class that implements the same interface as the object it wraps. Pythonic Implementation: Python has this pattern built directly into the language with the @ syntax for decorators, which we covered in Chapter 4. It's a prime example of Python providing a first-class solution.

import time
import functools

def timing_decorator(func):
    """A simple decorator to measure execution time."""
    @functools.wraps(func)
    def wrapper(*args, **kwargs):
        start = time.perf_counter()
        result = func(*args, **kwargs)
        end = time.perf_counter()
        print(f"{func.__name__} ran in {end - start:.4f}s")
        return result
    return wrapper

@timing_decorator
def complex_calculation(n):
    """Simulates a slow function."""
    return sum(i**2 for i in range(n))

complex_calculation(10_000_000)

Behavioral Patterns

These patterns are concerned with algorithms and the assignment of responsibilities between objects.

4. The Strategy Pattern

Intent: Define a family of algorithms, encapsulate each one, and make them interchangeable. Classic Implementation: An abstract Strategy interface with several concrete implementations. A Context class holds a reference to a strategy object. Pythonic Implementation: Again, first-class functions provide a much simpler path. Instead of a family of classes, you can have a family of functions.

# A collection of strategy functions
def fedex_shipping_cost(order):
    return 3.00 + (order['weight'] * 1.50)

def ups_shipping_cost(order):
    return 5.00 + (order['weight'] * 1.10)

def postal_shipping_cost(order):
    return 1.00 + (order['weight'] * 2.00)

class Order:
    def __init__(self, weight):
        self.weight = weight

    def get_shipping_cost(self, shipping_strategy):
        """The context class uses the strategy function."""
        return shipping_strategy(vars(self))

# Usage
order = Order(weight=5)

# We can easily switch the strategy at runtime
print(f"FedEx cost: ${order.get_shipping_cost(fedex_shipping_cost):.2f}")
print(f"UPS cost: ${order.get_shipping_cost(ups_shipping_cost):.2f}")
print(f"Postal cost: ${order.get_shipping_cost(postal_shipping_cost):.2f}")

This approach is more flexible and requires less boilerplate code than the classic class-based strategy pattern.

Summary

Design patterns are invaluable tools for architectural thinking. However, a senior Python developer understands that the intent of a pattern is more important than its classic UML diagram. In many cases, Python's dynamic features, first-class functions, and direct syntax allow you to achieve the same intent with code that is simpler, more readable, and more flexible than the original GoF implementations. The truly "Pythonic" approach is to understand the problem the pattern solves and then use the most direct language feature available to solve it.