Design Patterns, the Pythonic Way

In 1994, the “Gang of Four” (GoF) published Design Patterns, detailing 23 solutions to common software design problems. Because they used C++ and Smalltalk, many of these patterns rely on heavy class hierarchies and abstract interfaces.

In Python, however, we have first-class functions, decorators, and dynamic typing. Because of this, many GoF patterns collapse into just a few lines of code, or disappear entirely. Let’s look at the Pythonic alternatives.

The Strategy Pattern (First-Class Functions)

The Strategy pattern allows you to switch out algorithms at runtime. In Java, this requires defining an interface Strategy, creating multiple concrete classes that implement that interface, and passing instances of those classes to a context.

In Python, functions are first-class. You can just pass a function!

# The classic OOP way (Bloated)
class AbstractStrategy:
    def execute(self, data):
        pass

class MultiplyStrategy(AbstractStrategy):
    def execute(self, data):
        return [x * 2 for x in data]

# The Pythonic Way (Simple!)
def multiply_strategy(data):
    return [x * 2 for x in data]

def execute(data, strategy_func):
    return strategy_func(data)

print(execute([1, 2, 3], multiply_strategy))

[2, 4, 6]

The Factory Pattern (Dictionaries)

Factories abstract away the instantiation of objects. Instead of building massive Factory and AbstractFactory classes, Python leverages the fact that classes themselves are callable objects. You can store them in a dictionary!

class Dog:
    def speak(self): return "Woof!"

class Cat:
    def speak(self): return "Meow!"

# A perfect Pythonic Factory
animal_factory = {
    "dog": Dog,
    "cat": Cat
}

def create_animal(animal_type):
    if animal_type not in animal_factory:
        raise ValueError("Unknown animal")
    # Fetch the class object and call it () to instantiate
    return animal_factory[animal_type]()

pet = create_animal("dog")
print(pet.speak())

Woof!

The Registry Pattern (Decorators)

What if you don’t want to hardcode all the classes in your dictionary factory? What if users add their own classes in different files? Enter the Registry Pattern, elegantly solved via decorators.

_registry = {}

# A decorator that adds the class to our dictionary
def register(name):
    def decorator(cls_or_func):
        _registry[name] = cls_or_func
        return cls_or_func
    return decorator

@register("bird")
class Bird:
    def speak(self): return "Tweet!"

@register("fish")
class Fish:
    def speak(self): return "Blub"

print(f"Registered animals: {list(_registry.keys())}")
print(_registry["bird"]().speak())

Registered animals: ['bird', 'fish']
Tweet!

The Observer Pattern (Callback Lists)

The Observer pattern notifies multiple components when an event happens. Instead of making an Observer base class, Python simply uses a list of callback functions.

class EventDispatcher:
    def __init__(self):
        self._callbacks = []

    def subscribe(self, callback):
        self._callbacks.append(callback)

    def trigger_event(self, data):
        for callback in self._callbacks:
            callback(data)

def logger(data): 
    print(f"Log: {data}")

def alerter(data): 
    print(f"Alert: {data}")

dispatcher = EventDispatcher()
dispatcher.subscribe(logger)
dispatcher.subscribe(alerter)

dispatcher.trigger_event("Server started")

Log: Server started
Alert: Server started

The Singleton Pattern (Modules)

Many developers tie themselves in knots trying to override __new__ or write metaclasses to ensure a class only instantiates once.

The official, most Pythonic way to implement a Singleton? Just use a module.

When you import my_database in Python, the interpreter loads it exactly once and caches it in sys.modules. Any subsequent imports across your entire app just return a reference to that exact same cached module. Variables inside that module are naturally Singletons!