Behavioral design patterns

Structure tells you which objects exist; behavior tells you how they cooperate. The Hub's hardest behavioral problems are about change over time and about who needs to know what. When a node goes silent, the operations dashboard, the on-call technician, the customer's contract manager and the billing system all care, in different ways. A node moves through a lifecycle, from commissioning to active service, maintenance and retirement, and what it is allowed to do depends on where it is. Operators issue commands, such as re-aiming a node, that cannot be delivered until the node next connects, and that must be logged and sometimes undone. This lesson covers the behavioral patterns that solve these problems: strategy, observer, state and command, with shorter notes on iterator, chain of responsibility and visitor.

Strategy

The strategy pattern defines a family of algorithms, puts each in its own class behind a common interface, and makes them interchangeable, so the algorithm can vary independently of the code that uses it. You have already built one: the Classifier interface is a strategy, and ClassificationService is the context that holds one and delegates to it. The pattern's value is that choosing an algorithm becomes a matter of passing a different object, decided by configuration or even per request, instead of adding another branch to an if statement. In modern Java and Python, when a strategy has a single method, a lambda or a function is often the whole implementation: the Hub's interval rounding is a strategy chosen per customer, from rounding to the nearest 15 minutes to aligning with a city's signal-timing plan, and each is a one-line lambda stored in a map.

Strategy and the template method of lesson 7 solve a similar problem in opposite ways. Template method varies part of an algorithm by inheritance, fixed when the subclass is written. Strategy varies the whole algorithm by composition, and can change at run time. Following the advice of lesson 10, prefer strategy unless the steps genuinely share a lot of code and state.

Observer

The observer pattern defines a one-to-many dependency: when one object, the subject, changes state, all its registered observers are notified automatically. The subject knows only that its observers implement a small interface; it does not know what they do. In the Hub, the SilenceMonitor is a subject that publishes NodeWentSilent and NodeRecovered events. The dashboard observer turns a tile red, the paging observer sends a text message to the on-call technician if the node is on a priority corridor, the contract observer starts the clock on the customer's data-availability guarantee, and the billing observer marks the hours as not billable. Adding the contract observer last spring required no change to the monitor at all, which is the open-closed principle at work again.

Observer is everywhere in software: graphical user interfaces deliver button clicks to listener objects, spreadsheets recalculate cells when their inputs change, and publish-subscribe messaging systems apply the same idea across networks. Three practical issues come with it. First, a slow or failing observer must not block the others; the Hub catches exceptions from each listener and logs them, and runs slow listeners such as paging on a separate thread. Second, observers that register and never unregister are a classic memory leak, the listener form of the cache leak in lesson 3. Third, observers should not depend on the order in which they are notified, which is usually unspecified.

State

The state pattern lets an object change its behavior when its internal state changes, as if it had changed class. Each state is represented by an object implementing a common interface, and the context object delegates to its current state object and replaces it when a transition occurs. The alternative, a field holding a status code and a switch statement in every method, scatters the rules for each state across the whole class, exactly the problem polymorphism solved in lesson 6. A node in the Hub is Commissioning when installed but not yet verified, Active when counting normally, Silent when it has missed uploads, InMaintenance when a technician has taken it offline, and Retired at the end of its life. Uploads are accepted and billed only when Active; an upload from a Silent node moves it back to Active and closes the alert; an upload from a node InMaintenance is stored but flagged as test data; and a Retired node's uploads are rejected.

UML state machine diagrams, like the one above, are a natural companion to the state pattern and to the finite state machines of CMP-210 and ELE-210 Digital Logic Design: states are rounded boxes, transitions are arrows labeled with the event that triggers them, and a filled circle marks the start. In code, each state class implements handlers such as onUpload and onTimeout, returning the next state. Java enums can implement the pattern compactly, because each enum constant can override methods, and a sealed interface with records works well too.

public sealed interface NodeState permits Commissioning, Active, Silent, InMaintenance, Retired {
    NodeState onUpload(NodeContext ctx, Upload u);
    default NodeState onTimeout(NodeContext ctx) { return this; }
}

public record Active() implements NodeState {
    public NodeState onUpload(NodeContext ctx, Upload u) { ctx.storeAndBill(u); return this; }
    public NodeState onTimeout(NodeContext ctx) { ctx.events().publishSilent(ctx.node()); return new Silent(); }
}

public record Silent() implements NodeState {
    public NodeState onUpload(NodeContext ctx, Upload u) {
        ctx.storeAndBill(u);
        ctx.events().publishRecovered(ctx.node());
        return new Active();
    }
}

public final class NodeContext {
    private NodeState state = new Commissioning();
    public void upload(Upload u) { state = state.onUpload(this, u); }     // delegate, then transition
    public void timeout()        { state = state.onTimeout(this); }
    // storeAndBill, events(), node() ...
}

Command

The command pattern turns a request into an object. Instead of calling node.reaim(lanes) directly, the operator console creates a ReaimCommand holding the node, the new lanes and the old lanes, and hands it to a command processor. Because the request is now an object, it can be queued, logged, sent across a network, scheduled for later, retried and undone. This fits the Hub exactly: a node can only receive configuration when it next connects, so commands wait in a per-node queue and are delivered at the next upload. Every command is written to an audit log with the operator's name and the time, which the city's contract requires. And because a ReaimCommand remembers the old lanes, an operator who aims a node at the wrong lanes can undo it.

from collections import deque

# Observer: the monitor notifies listeners without knowing what they do
class SilenceMonitor:
    def __init__(self): self._listeners = []
    def subscribe(self, listener): self._listeners.append(listener)
    def publish(self, event, node_id):
        for listener in self._listeners:
            try:
                listener(event, node_id)
            except Exception as e:                    # one bad listener must not stop the rest
                print(f"  listener failed: {e}")

log = []
monitor = SilenceMonitor()
monitor.subscribe(lambda ev, n: log.append(f"dashboard: node {n} {ev}"))
monitor.subscribe(lambda ev, n: log.append(f"pager: node {n} {ev}") if n in {4417} else None)
monitor.subscribe(lambda ev, n: 1 / 0)                # a buggy listener

# State: each state decides what an event means and which state follows
class Active:
    def upload(self, node): node.billed += 1; return self
    def timeout(self, node): monitor.publish("silent", node.node_id); return Silent()
class Silent:
    def upload(self, node):
        node.billed += 1; monitor.publish("recovered", node.node_id); return Active()
    def timeout(self, node): return self
class InMaintenance:
    def upload(self, node): node.test_uploads += 1; return self
    def timeout(self, node): return self              # no alerts during maintenance

class Node:
    def __init__(self, node_id):
        self.node_id, self.state, self.billed, self.test_uploads = node_id, Active(), 0, 0
        self.lanes, self.pending = (1, 2, 3, 4), deque()
    def upload(self):
        self.state = self.state.upload(self)
        while self.pending:                            # deliver queued commands at check-in
            self.pending.popleft().execute()
    def timeout(self): self.state = self.state.timeout(self)

# Command: a request as an object that can be queued, logged and undone
class ReaimCommand:
    def __init__(self, node, lanes, operator):
        self.node, self.new, self.old, self.operator = node, tuple(lanes), None, operator
    def execute(self):
        self.old, self.node.lanes = self.node.lanes, self.new
        print(f"  {self.operator}: node {self.node.node_id} lanes {self.old} -> {self.new}")
    def undo(self):
        self.node.lanes = self.old
        print(f"  undo: node {self.node.node_id} lanes back to {self.old}")

n = Node(4417)
n.upload(); n.timeout(); n.timeout(); n.upload()
print("state:", type(n.state).__name__, "| billed uploads:", n.billed)
print("\n".join(log))
cmd = ReaimCommand(n, [1, 2], "D. Whitcombe")
n.pending.append(cmd)                                  # queued until the node connects
print("queued; lanes still", n.lanes)
n.upload()
cmd.undo()
n.state = InMaintenance(); n.upload(); n.timeout()
print("maintenance uploads:", n.test_uploads, "| billed:", n.billed)

  listener failed: division by zero
  listener failed: division by zero
state: Active | billed uploads: 2
dashboard: node 4417 silent
pager: node 4417 silent
dashboard: node 4417 recovered
pager: node 4417 recovered
queued; lanes still (1, 2, 3, 4)
  D. Whitcombe: node 4417 lanes (1, 2, 3, 4) -> (1, 2)
  undo: node 4417 lanes back to (1, 2, 3, 4)
maintenance uploads: 1 | billed: 3

Trace the output against the patterns. The node bills an upload while active, the first timeout makes it silent and notifies the listeners, the second timeout does nothing more because a silent node is already silent, and the next upload bills again and announces recovery. The buggy listener fails twice without stopping the dashboard or the pager. The re-aim command waits in the queue until the next upload, executes, and is undone with the old lanes it remembered. During maintenance, uploads are counted as test data and timeouts raise no alerts, all without a single if statement on a status code.

Three more patterns in brief

The iterator pattern, which provides a way to traverse a collection without exposing its structure, is so useful that languages have built it in: Java's Iterator and for-each loop and Python's iterators and generators from lesson 9 are the pattern. The chain of responsibility pattern passes a request along a chain of handlers until one deals with it, or, in a common variant, through every handler in turn. The Hub's data-quality pipeline is such a chain: a duplicate filter, a plausibility filter, a unit-consistency check and a clock-skew corrector each examine a detection, and adding a new check means inserting one more handler. The visitor pattern separates an operation from the classes it operates on, letting you add new operations over a fixed class hierarchy without editing it; Java 21's pattern matching over sealed types, shown in lesson 6, now covers many of the cases where visitor was once needed.