Design patterns

1 · What patterns are (and aren't) essential

Here's a scene you've probably sat through. Two engineers are staring at the same pull request, and one says "this should just be a Strategy." The other nods, and in three words a whole design decision is settled — no whiteboard, no long explanation, no arguing about the shape of the code. That's the real superpower of design patterns: not the code, but the shared vocabulary. A pattern is a name for a solution that so many people have reached independently that it earned its own word, the way "sandwich" saves you from saying "a filling between two slices of bread."

Think of them as recipes rather than ingredients. A recipe doesn't hand you the finished dish — it captures the shape of a good solution that generations of cooks converged on, so you don't rediscover it from scratch every time. When you learn "Observer," you're not memorizing lines to paste; you're learning to recognize a family of problems ("many things need to react when one thing changes") and the shape that reliably solves it. That recognition is what lets a senior engineer glance at a tangle of if-statements and say "that wants to be a State machine" — they've seen the pattern's silhouette before.

Now the mistake that makes patterns notorious — and it's worth naming loudly because it's the whole reason this section leads with a caution. Beginners who just learned patterns start seeing them everywhere and cram them in where a plain function would do. You end up with an AbstractWidgetFactoryProvider to build something a one-line dictionary lookup would have handled — a phenomenon so common it has a mocking nickname, "cargo-culting." Patterns are tools for a problem you actually have, not trophies to collect. The right instinct is the reverse: write the simplest thing that works, and reach for a pattern only when the simple thing starts to hurt (you're editing five files to add one option; a change in one place breaks three others). The pattern earns its keep by removing pain, never by adding ceremony.

This matters doubly in Python, and it's the running theme of this whole chapter. Many classic patterns were invented for languages like Java or C++, where the type system forces you to build scaffolding — interfaces, class hierarchies, factory objects — just to pass behavior around. Python has first-class functions (you can hand a function to another function like any other value), so several patterns that need a page of classes elsewhere collapse into "just pass a function." A Strategy is a function argument; a Singleton is a module you import. Knowing the pattern still matters — it names the problem and signals your intent to teammates — but the Pythonic implementation is often almost free. Below, the patterns are grouped into three families by what kind of problem they solve.

A design pattern is a named, reusable solution to a recurring design problem — shared vocabulary more than code to copy. Three families. Caution: patterns are tools, not goals; Python's first-class functions make several patterns nearly free.

2 · Creational — Factory & Singleton essential

Picture the bug that teaches this pattern. Your codebase talks to S3 for storage, and you wrote S3() in forty different files. Then the client moves to a local disk for dev, and you're on a scavenger hunt through all forty, changing each one — and you miss two, and they only break in production at 2am. Every one of those S3() calls was a decision ("use S3") baked into a place that had no business making that decision. Creational patterns exist to pull the "which object do I build?" decision out of the code that just wants to use the object.

A Factory is the fix, and the everyday analogy is a restaurant kitchen. You order "the pasta" — you don't walk in and personally assemble it, and you certainly don't need to know whether the chef changed the recipe last week. One place (the kitchen, the factory function) knows how to build the thing; everyone else just asks by name. In code that means the caller says make_storage("s3") instead of S3(), so the day you swap backends you edit one lookup table and every one of those forty call sites keeps working, untouched.

A Singleton solves a different worry: "there must be exactly one of this." One config object, one connection pool, one logger — because if two parts of your program each made their own, they'd disagree, or you'd open twice the database connections you meant to. The picture is a building's single thermostat: everyone shares it, and turning it up in one room turns it up for the whole floor, because there's only one. In classic languages you enforce this with a special class that hands back the same instance every time (you'll see exactly that __new__ trick below).

Where the "don't over-apply" warning bites hardest — and it's the Singleton. The Singleton is the most abused pattern in the book, because a shared global object is really just a global variable wearing a costume, and globals make code hard to test (you can't swap in a fake) and hard to reason about (anyone can mutate it from anywhere). And in Python the ceremony is usually pointless: a module is already a singleton — import the same module twice and you get the same object — so a plain module-level object gives you "exactly one shared thing" for free, no class required. Reach for the class-based version only when you genuinely need lazy creation or subclass control; the rest of the time, prefer the module global (the practice ladder drives this home). Factories, by contrast, earn their keep the moment you have more than one "kind" to choose between at runtime.

creational.pyfrom abc import ABC, abstractmethod

class Storage(ABC):
    @abstractmethod
    def save(self, key): ...
class S3(Storage):
    def save(self, key): return f"S3:{key}"
class Local(Storage):
    def save(self, key): return f"local:{key}"

def make_storage(kind) -> Storage:            # FACTORY: callers don't name classes
    return {"s3": S3, "local": Local}[kind]()

class Config:                                 # SINGLETON: one shared instance
    _instance = None
    def __new__(cls):
        if cls._instance is None:
            cls._instance = super().__new__(cls); cls._instance.data = {}
        return cls._instance

print(make_storage("s3").save("a"), make_storage("local").save("b"))
print("same config:", Config() is Config())

S3:a local:b
same config: True

3 · Structural — Decorator & Adapter intermediate

Here's a rule you'll be handed on your first real team, and it feels maddening at first: "don't edit that class." Maybe it's shared by ten other teams, maybe it's third-party code you don't own, maybe it's load-bearing and nobody dares touch it. But you still need it to do something more — cache its results, log its calls, speak a different dialect. Structural patterns are the answer to "how do I change what an object does without opening it up?" They're about composition: snapping objects together so the combination does the new thing, while each original piece stays exactly as it was.

A Decorator is a gift box, and the analogy is worth taking literally. You wrap the original object in a new one that has the same shape (the same methods), so from the outside nobody can tell it's wrapped — but on the way in and out, the wrapper adds its own touch. Want to cache a slow fetcher? Wrap it: the wrapper checks its memory first and only calls the real fetcher on a miss. The fetcher never learns it's been wrapped, and you can stack wrappers (caching and logging and retry) like nesting boxes. This is the Open/Closed principle from SD3 made concrete — the class is closed to editing but open to extension through wrapping.

An Adapter solves a different mismatch: two things that should fit but don't, because their interfaces disagree. The physical analogy is the plug adapter in your travel bag — your laptop charger and the foreign wall socket both do "electricity," but the shapes don't match, so a little in-between piece translates one to the other. In code, a third-party sensor reports Celsius but your whole app is built around Fahrenheit; rather than sprinkle conversions everywhere, you write one adapter that presents the Fahrenheit interface your code expects and quietly does the ×9/5+32 inside. Your code depends only on the interface it always wanted; the foreign quirk is sealed in one place.

The tension to watch — and where beginners over-apply. Both patterns add a layer, and layers aren't free: another object to trace through when debugging, another hop for a reader to follow. The honest test is "am I absorbing a real mismatch or hiding a fixable one?" If you own the class and can just change it, change it — don't wrap your own code in an adapter to avoid a five-minute edit; that's ceremony, not design. Reach for a Decorator when the concern is genuinely cross-cutting (caching, logging, timing — things you'd otherwise copy into every method), and for an Adapter when the code you must fit is genuinely not yours to change. Used for those, they're clean; used to dodge a simple refactor, they're just indirection.

structural.pyclass DataSource:
    def get(self, key):
        print(f"  fetch {key}"); return f"value:{key}"

class Caching:                                 # wraps another DataSource
    def __init__(self, inner): self.inner, self._c = inner, {}
    def get(self, key):
        if key not in self._c: self._c[key] = self.inner.get(key)
        return self._c[key]

ds = Caching(DataSource())
print(ds.get("x")); print(ds.get("x"))         # 2nd call: no fetch

  fetch x
value:x
value:x

4 · Behavioral — Strategy & Observer (the Pythonic way) advanced

Every codebase has that one function — the one everyone's afraid of. It sorts results, and over two years it grew a staircase of if mode == "price": ... elif mode == "name": ... elif mode == "rating": ..., and now adding a fourth sort means editing the scary function again and re-testing all three old branches so you don't break them. That growing if/elif ladder is a smell, and behavioral patterns are the deodorant. They're about how objects talk to each other — who decides what, who tells whom — and they exist to keep that conversation flexible instead of hard-wired.

The Strategy pattern kills the if/elif ladder by turning each branch into a swappable piece. The analogy is a GPS asking "fastest, shortest, or scenic route?" — same trip, same machine, but you plug in a different algorithm for computing the route. Instead of the sort function knowing about every possible ordering, you hand it the ordering you want as a parameter, and it just applies whatever it's given. Adding a new sort is now writing a new little piece and passing it in — the scary function never changes, so there's nothing old to break.

The Observer pattern solves "when this happens, a bunch of other things need to know." Think of a group chat, or a magazine subscription: when an order is placed, the email service wants to know, and analytics wants to know, and inventory wants to know — but the order-placing code shouldn't have to hold a list of all of them and call each by hand (that list would grow forever, and order-placement would be entangled with everything downstream). Instead, interested parties subscribe, and the event just broadcasts; the publisher never learns who's listening or what they do. Add a new subscriber and nothing else changes.

And here is the punchline of this whole chapter, so read it twice. In Java, both of these are ceremonies: Strategy is an interface plus one class per algorithm; Observer is a Subject interface, an Observer interface, and registration boilerplate. In Python, a function is a value you can pass around and store in a list — so a Strategy is just a function argument (that's exactly what sorted(items, key=...) already is, a Strategy hiding in the standard library), and an Observer's subscriber list is just a list of functions. You will genuinely almost never write the class-heavy textbook version in Python; if you find yourself building a Strategy base class with subclasses, stop — that's the over-application trap, importing another language's tax into a language that doesn't charge it. Know the pattern so you recognize the problem, then reach for the plain function that solves it.

behavioral.py# STRATEGY: a strategy is just a callable
def by_price(i): return i["price"]
def by_name(i):  return i["name"]
def sort_items(items, key): return sorted(items, key=key)

items = [{"name": "pen", "price": 3}, {"name": "book", "price": 1}]
print([i["name"] for i in sort_items(items, by_price)])   # cheapest first

# OBSERVER: subscribers are just functions in a list
class Event:
    def __init__(self): self._subs = []
    def subscribe(self, fn): self._subs.append(fn)
    def fire(self, data):
        for fn in self._subs: fn(data)

order_placed = Event()
order_placed.subscribe(lambda o: print(f"email: order {o}"))
order_placed.subscribe(lambda o: print(f"analytics: {o}"))
order_placed.fire("A1")

['book', 'pen']
email: order A1
analytics: A1

5 · Machine-coding round #1 — rate limiter advanced

The clock is running and your mind goes blank — that's the machine-coding round. Unlike a LeetCode puzzle with one clever trick, this interview asks you to build a small real component in about 45 minutes: not a toy that returns the right answer, but something with a clean interface, sensible classes, and a test that proves it works. It rattles people because there's no single "aha"; it's judged on whether you write code the way a professional writes code under mild pressure. The good news is that it rewards process, and the process is learnable — which is exactly what the patterns you just met are for.

This is where design vocabulary stops being academic and starts saving your interview. When you can say "I'll inject the clock so this is testable" (Dependency Inversion, SD3) or "the eviction policy is a Strategy so we can swap LRU for LFU later," you're not reciting patterns — you're using them as the shorthand that lets you design out loud, fast, while your hands are busy typing. The first prompt below is a canonical one: a rate limiter, the thing that stops a client from hammering your API a thousand times a second. It looks intimidating and turns out to be a dozen honest lines.

The single most common mistake here isn't the algorithm — it's calling time.time() inside the limiter, which makes it impossible to test without literally sleeping in real time. The fix is small and interviewers love it: pass the current time in as an argument (allow(now)). Suddenly you can feed it fake times and assert exact behavior at t=1000, t=1001, no waiting. Watch for that "inject the clock" move — it's the tell that separates someone who's done this from someone reciting a blog post.

Interviews include a machine-coding round: a small, clean, working component in ~45 min. Approach: clarify the interface, pick the algorithm, write SOLID classes, self-test.

How to run a machine-coding round

1. Clarify requirements + the exact interface (methods, inputs, outputs).
2. Pick the core algorithm/data structure.
3. Write clean, single-responsibility, testable code (inject the clock!).
4. Add a self-test that proves it; mention thread-safety + extensions.

rate_limiter.pyimport threading

class RateLimiter:
    """Allow `rate` req/sec, bursting up to `capacity` tokens. Clock injected -> testable."""
    def __init__(self, rate, capacity):
        self.rate, self.capacity = rate, capacity
        self.tokens = capacity; self.updated = None
        self._lock = threading.Lock()
    def allow(self, now):
        with self._lock:
            if self.updated is None: self.updated = now
            self.tokens = min(self.capacity, self.tokens + (now - self.updated) * self.rate)
            self.updated = now
            if self.tokens >= 1:
                self.tokens -= 1; return True
            return False

rl = RateLimiter(rate=2, capacity=2)
print([rl.allow(1000.0) for _ in range(3)])   # [True, True, False]
print(rl.allow(1001.0))                        # True — refilled after 1s

[True, True, False]
True

6 · Machine-coding round #2 — LRU cache expert

Your cache is full and something has to go — but what? That one question is why the LRU cache is the second machine-coding staple, and why it's a step harder than the rate limiter. A cache is a small, fast box that remembers recent answers so you don't redo expensive work; the moment it fills up, you must evict something to make room. "Least Recently Used" is the sensible bet: throw out whatever you haven't touched in the longest time, because it's the least likely to be needed next. Your phone does exactly this with the apps it keeps warm in memory — open one you haven't used in days and it reloads, because the OS quietly evicted it.

The reason this earns "expert" is a genuine tension: the interviewer wants both get and put to be O(1) — instant, no matter how big the cache. A plain dictionary gives you O(1) lookup but forgets order, so finding "the least recently used item" would mean scanning everything (O(n)). A sorted list keeps order but slow inserts. The classic answer is to combine two structures: a hash map for instant lookup, and a doubly-linked list for instant reordering and eviction — each covering the other's weakness. Being able to explain why you need both is half the score.

Then comes the Python punchline — and the trap of not knowing it. You can hand-roll the hash-map-plus-linked-list, and in a C++ or Java interview you'd have to. But Python ships collections.OrderedDict, which is precisely that combination already built and battle-tested: move_to_end marks an item freshly-used in O(1), and popitem(last=False) evicts the oldest in O(1). Reaching for it isn't cheating — it's showing you know the standard library, which is exactly what a real engineer does instead of reinventing a subtle data structure at 45-minute pace. (Know the manual version too, because some interviewers specifically ask for it to test the fundamentals — but lead with the clean one.) This exact component powers the caching layer you'll build in SD5.

A second, harder round: an LRU cache with O(1) get/put. The trick is combining a hash map (for lookup) with a doubly-linked order (for eviction) — Python's OrderedDict gives both. This exact component powers SD5's caching.

lru_cache.pyfrom collections import OrderedDict

class LRUCache:
    """O(1) get/put; evicts least-recently-used when full."""
    def __init__(self, capacity):
        self.cap = capacity; self._d = OrderedDict()
    def get(self, key):
        if key not in self._d: return -1
        self._d.move_to_end(key); return self._d[key]
    def put(self, key, value):
        if key in self._d: self._d.move_to_end(key)
        self._d[key] = value
        if len(self._d) > self.cap: self._d.popitem(last=False)

c = LRUCache(2)
c.put(1, "a"); c.put(2, "b")
assert c.get(1) == "a"          # 1 is now most-recent
c.put(3, "c")                    # evicts 2 (least-recent)
assert c.get(2) == -1
assert c.get(3) == "c"
print("LRU cache passes its self-test")

LRU cache passes its self-test

class Circle:  area = lambda self: 3.14159
class Square:  area = lambda self: 4.0

def shape_factory(kind):
    return {"circle": Circle, "square": Square}[kind]()

print(round(shape_factory("circle").area(), 2))   # 3.14
print(shape_factory("square").area())             # 4.0

# Class-based (works, but verbose):
class Config:
    _instance = None
    def __new__(cls):
        if cls._instance is None:
            cls._instance = super().__new__(cls)
        return cls._instance

print(Config() is Config())   # True

# Pythonic shortcut: just use a module-level object.
CONFIG = {"env": "prod"}       # import it anywhere; one shared object
CONFIG["env"] = "staging"
print(CONFIG)                  # {'env': 'staging'}

import functools

def counted(fn):
    @functools.wraps(fn)
    def wrapper(*a, **k):
        wrapper.calls += 1
        return fn(*a, **k)
    wrapper.calls = 0
    return wrapper

@counted
def add(a, b): return a + b

add(1, 2); add(3, 4)
print(add.calls)          # 2
print(add(5, 6))          # 11

class CelsiusSensor:                  # third-party, can't change
    def read_c(self): return 25.0

class TemperatureReader:              # what our app expects
    def read_f(self): raise NotImplementedError

class CelsiusAdapter(TemperatureReader):
    def __init__(self, sensor): self.sensor = sensor
    def read_f(self): return self.sensor.read_c() * 9 / 5 + 32

reader = CelsiusAdapter(CelsiusSensor())
print(reader.read_f())   # 77.0

class RateLimiter:
    def __init__(self, limit, window):
        self.limit, self.window = limit, window
        self.count, self.window_start = 0, 0
    def allow(self, now):
        if now - self.window_start >= self.window:   # new window
            self.window_start, self.count = now, 0
        if self.count < self.limit:
            self.count += 1
            return True
        return False

rl = RateLimiter(limit=2, window=10)
print([rl.allow(t) for t in (0, 1, 2)])   # [True, True, False]  (3rd in window blocked)
print(rl.allow(11))                        # True  (new window at t=11)

from collections import OrderedDict

class LRUCache:
    def __init__(self, capacity):
        self.cap = capacity
        self.d = OrderedDict()
    def get(self, key):
        if key not in self.d: return -1
        self.d.move_to_end(key)          # mark as recently used
        return self.d[key]
    def put(self, key, value):
        if key in self.d: self.d.move_to_end(key)
        self.d[key] = value
        if len(self.d) > self.cap:
            self.d.popitem(last=False)   # evict least-recently-used

c = LRUCache(2)
c.put(1, "a"); c.put(2, "b")
print(c.get(1))       # a  (now 1 is most-recent)
c.put(3, "c")         # evicts key 2 (least-recent)
print(c.get(2))       # -1 (evicted)
print(c.get(3))       # c

Knowledge check check yourself