Design patterns across paradigms

A design pattern is a named, reusable solution to a problem that keeps recurring in software design. The idea came from the architect Christopher Alexander, who cataloged patterns for buildings and towns, and reached programming through the 1994 book Design Patterns by Gamma, Helm, Johnson and Vlissides, often called the Gang of Four. Their 23 patterns were written for C++ and Smalltalk, languages without first-class functions. Many of the patterns are workarounds for exactly that gap, and in a language with closures they shrink to a few lines. This lesson studies a handful of the most useful patterns, shows each in its classic object-oriented form, and then shows what it becomes in functional style. The lesson is about recognizing the problem each pattern solves; CMPUT-301 covers patterns in the context of large, team-built systems.

What a pattern is and is not

A pattern has four parts: a name, the problem it addresses, the solution's structure, and the consequences, including trade-offs. The name is surprisingly valuable, because it lets designers communicate quickly: saying use an observer here conveys a whole structure in three words. A pattern is not a piece of code you copy. It is a design idea that you adapt to the language and the problem. Forcing patterns into code that does not need them produces needless indirection, a mistake so common it has its own joke: the program with an AbstractSingletonProxyFactoryBean.

Strategy

The strategy pattern lets a client choose one of several algorithms at run time. In the classic form, each algorithm is a class implementing a common interface, and the client holds a reference to one of them. Lesson 5's `Notifier` used strategies for channels and policies. When a strategy has a single method and no state, a function is all you need: the strategy object becomes a function value, and the interface becomes a function signature.

from abc import ABC, abstractmethod

# Classic object-oriented strategy
class Pricing(ABC):
    @abstractmethod
    def price(self, base): ...
class Regular(Pricing):
    def price(self, base): return base
class Student(Pricing):
    def price(self, base): return round(base * 0.85, 2)
class Weekend(Pricing):
    def __init__(self, surcharge): self.surcharge = surcharge
    def price(self, base): return base + self.surcharge

def checkout_oo(base, strategy: Pricing):
    return strategy.price(base)

# Functional strategy: the strategy IS a function
regular = lambda base: base
student = lambda base: round(base * 0.85, 2)
def weekend(surcharge): return lambda base: base + surcharge   # closure holds the state

def checkout_fn(base, strategy):
    return strategy(base)

for oo, fn in [(Regular(), regular), (Student(), student), (Weekend(3), weekend(3))]:
    print(checkout_oo(14.0, oo), checkout_fn(14.0, fn))

14.0 14.0
11.9 11.9
17.0 17.0

The functional version needs no abstract class and no subclass per algorithm, and the `weekend` closure carries its surcharge just as the `Weekend` object did. The class version still has a place when a strategy has several related methods, needs configuration and inspection, or must be documented as a named type in a large codebase. In Python, `sorted(items, key=...)` is the strategy pattern built into the standard library: the key function is the interchangeable algorithm.

Observer

The observer pattern connects a subject, which has some state, to any number of observers that want to know when the state changes. Observers register with the subject, and the subject calls each of them when something happens. The subject does not need to know what the observers do, which keeps it decoupled from the rest of the program. Graphical user interfaces are built on this pattern: a button is a subject, and click handlers are observers.

class Thermostat:
    def __init__(self):
        self._observers = []
        self._temp = 20.0
    def subscribe(self, callback):
        self._observers.append(callback)
        return lambda: self._observers.remove(callback)   # returns an unsubscribe function
    def set_temp(self, t):
        old, self._temp = self._temp, t
        for cb in list(self._observers):
            cb(old, t)

log = []
th = Thermostat()
th.subscribe(lambda old, new: print(f"display: {new:.1f} C"))
stop_log = th.subscribe(lambda old, new: log.append((old, new)))
th.subscribe(lambda old, new: new > 26 and print("alarm: too hot"))

th.set_temp(22.5)
th.set_temp(27.0)
stop_log()                         # unsubscribe the logger
th.set_temp(21.0)
print("log:", log)

display: 22.5 C
display: 27.0 C
alarm: too hot
display: 21.0 C
log: [(20.0, 22.5), (22.5, 27.0)]

Two details matter in real systems. The subject iterates over a copy of the observer list, `list(self._observers)`, so that an observer can unsubscribe during notification without disturbing the loop. And forgetting to unsubscribe is a common cause of memory leaks, because the subject keeps observers alive. Returning an unsubscribe function, as here, makes clean-up easy. Lesson 11 shows how reactive programming generalizes observers into streams of events that can be filtered, mapped and combined.

Command

The command pattern turns a request into a value. Instead of calling a method directly, you create a command object that knows how to perform the action and, often, how to undo it. Commands can be stored in a list, sent to another thread, logged for auditing, replayed or reversed. Text editors implement undo and redo this way. In functional style, a command can be a pair of closures, one to do and one to undo, or simply an immutable record describing the action, interpreted by a single function.

class Editor:
    def __init__(self):
        self.text, self.undo_stack = "", []
    def run(self, do, undo):
        do(self); self.undo_stack.append(undo)
    def undo(self):
        if self.undo_stack:
            self.undo_stack.pop()(self)

def insert(s):
    def do(ed): ed.text += s
    def undo(ed): ed.text = ed.text[:-len(s)]
    return do, undo

def upper():
    saved = {}
    def do(ed): saved["before"] = ed.text; ed.text = ed.text.upper()
    def undo(ed): ed.text = saved["before"]
    return do, undo

ed = Editor()
for cmd in [insert("hello"), insert(" world"), upper()]:
    ed.run(*cmd)
    print(repr(ed.text))
while ed.undo_stack:
    ed.undo(); print("undo ->", repr(ed.text))

'hello'
'hello world'
'HELLO WORLD'
undo -> 'hello world'
undo -> 'hello'
undo -> ''

Factory

A factory creates objects without the caller naming their concrete classes. The caller asks for a shape from a description, or a parser for a file type, and the factory decides which class to instantiate. This keeps knowledge of concrete classes in one place, so adding a new kind means changing only the factory. In Python, classes are themselves callable values, so a factory is often just a dictionary from names to classes or constructor functions.

import json, csv, io

def parse_json(text): return json.loads(text)
def parse_csv(text):  return list(csv.DictReader(io.StringIO(text)))

PARSERS = {".json": parse_json, ".csv": parse_csv}     # the factory's registry

def parser_for(filename):
    for ext, parser in PARSERS.items():
        if filename.endswith(ext):
            return parser
    raise ValueError(f"no parser for {filename}")

def register(ext):                                     # plug-ins add themselves
    def wrap(fn):
        PARSERS[ext] = fn; return fn
    return wrap

@register(".kv")
def parse_kv(text):
    return dict(line.split("=", 1) for line in text.splitlines() if line)

print(parser_for("a.json")('{"x": 1}'))
print(parser_for("b.csv")("name,age\nAna,30\nBen,25"))
print(parser_for("c.kv")("host=db1\nport=5432"))

{'x': 1}
[{'name': 'Ana', 'age': '30'}, {'name': 'Ben', 'age': '25'}]
{'host': 'db1', 'port': '5432'}

The `register` function is itself a small pattern: a decorator that adds the decorated function to a registry. Web frameworks use the same idea to map URLs to handler functions. Adding the `.kv` format required no change to `parser_for`; that is the open–closed principle from lesson 5 achieved with a dictionary and a higher-order function.

Decorator

The decorator pattern adds behavior to an object by wrapping it in another object with the same interface. The wrapper does extra work, such as logging, caching or checking permissions, and delegates the main work to the wrapped object. Python's decorator syntax, `@name` above a function definition, applies the functional version: a higher-order function that takes a function and returns a wrapped one. The two ideas share a name because they solve the same problem.

import functools, time

def timed(fn):
    @functools.wraps(fn)
    def wrapper(*args, **kwargs):
        start = time.perf_counter()
        result = fn(*args, **kwargs)
        wrapper.last_ms = (time.perf_counter() - start) * 1000
        return result
    return wrapper

def memoize(fn):
    cache = {}
    @functools.wraps(fn)
    def wrapper(n):
        if n not in cache:
            cache[n] = fn(n)
        return cache[n]
    wrapper.cache = cache
    return wrapper

@timed
@memoize
def fib(n):
    return n if n < 2 else fib(n - 1) + fib(n - 2)

print(fib(80), "| cached values:", len(fib.__wrapped__.cache))
print("name preserved by wraps:", fib.__name__)

23416728348467685 | cached values: 81
name preserved by wraps: fib

The memoized Fibonacci runs in linear time because each value is computed once, a preview of the dynamic programming in CMPUT-304. Memoization is only safe for pure functions, the point made in lesson 2. The standard library provides `functools.cache` and `functools.lru_cache` for exactly this purpose. `functools.wraps` copies the wrapped function's name and documentation onto the wrapper and records the original in `__wrapped__`, so tools and error messages still show the right name.