Behavioral Patterns

Behavioral patterns describe how objects talk to each other and who is responsible for what. Creational patterns are about how objects get made; structural patterns are about how objects are composed into bigger shapes.

Both let part of an algorithm vary. Template Method uses inheritance: a base class fixes the steps and subclasses override some of them. Strategy uses composition: the varying algorithm is a separate object you plug in, swappable at runtime.

Strategy plugs in one interchangeable algorithm chosen by the caller. State makes an object behave differently as its internal state changes, with states deciding the transitions. Command wraps a request — action plus its arguments — into an object you can queue, log, or undo.

Observer broadcasts a change to every registered listener. Mediator puts one coordinator in the middle so components talk to it instead of each other. Chain of Responsibility passes a request down a line of handlers until one handles it.

Visitor lets you add new operations over a fixed set of node types without editing them. It needs two dispatches: the node picks accept(visitor), then calls visitor.visitX(this), so the right method is chosen by both the node type and the visitor type. The trade-off: adding an operation is easy, adding a node type breaks every visitor.

Observer defines a one-to-many dependency: many observers register with one subject, and when the subject's state changes it notifies them all automatically. The subject knows only an abstract observer interface, not the concrete observers.

Push means the subject sends the changed data with the notification (update(newValue)). Pull means the notification only says "something changed" and each observer calls back into the subject to read what it needs. Push is efficient but guesses what observers want; pull is flexible but couples observers to the subject's query API.

A subject keeps a strong reference to every registered observer. If an observer is discarded without unsubscribing, the subject keeps it alive forever — it leaks memory and keeps receiving events it should no longer handle.

Observers are usually called in registration order, which is accidental, so nothing should depend on it. An observer that changes the subject during update() can trigger recursive notification or infinite loops, and one change can fan out into thousands of updates. Fixes: snapshot iteration, reentrancy guards, batching, and change coalescing.

Use in-process Observer when subject and observers live in the same process and must react immediately. Move to a broker when the reactors are separate services or must survive restarts. You gain durability, retries and independent scaling; you lose synchronous ordering and immediate consistency, and you must handle duplicates.

Strategy defines a family of interchangeable algorithms, puts each one behind the same interface, and lets the calling code pick which one to use at runtime — so you swap behavior instead of editing a big if/else.

Same structure, different intent. In Strategy the client picks one algorithm and it usually stays fixed; the variants don't know about each other. In State the object's own behavior changes as its lifecycle advances, and states typically trigger the transitions to the next state.

Extract each branch into its own object implementing one shared interface, replace the branching call site with a delegation, and move the choice into one place — a factory or a map from key to strategy — that the client uses to pick the right implementation.

If the strategy is one operation with no state and no extra methods, a function value is the whole pattern — a lambda is an object with one method. Prefer a named interface or class when the strategy needs configuration, identity, a name for DI/registry lookup, or more than one operation.

Strategy swaps a whole algorithm via composition, chosen at runtime. Template Method fixes the algorithm's skeleton in a base class and lets subclasses override individual steps, bound at compile time by inheritance. Bridge splits an abstraction hierarchy from an implementation hierarchy so both can grow independently.

A base type defines one method holding the fixed steps of an algorithm, in a fixed order. Some of those steps are left unimplemented, and subtypes fill them in. The overall shape stays the same for every subtype.

Both let part of an algorithm vary. Template Method varies it by inheritance: a subclass overrides a step inside a fixed base-class algorithm. Strategy varies it by composition: you hand the object a separate step-object, which can be swapped at runtime.

Make a step abstract when the algorithm cannot run without it, so every subclass is forced to supply it. Make it a hook with a default when it is optional extra behaviour. Keep the main method non-overridable and the steps narrowly visible so no subclass can reorder or skip anything.

It relies on inheritance, so the variant is fixed when the object is created, only one axis can vary, and subclasses depend on the base class's internals — a base-class change can break them. When it hurts, move the varying steps into injected objects or functions (Strategy) instead of subclasses.

Treat every step as published API. Never add a required step or reorder existing ones; add optional hooks with defaults that keep current behaviour, deprecate slowly with clear migration notes, and offer a composition-based alternative for the next major version.

Iterator gives a standard way to walk a collection's elements one at a time. The collection hands you a small cursor object with "is there more?" and "give me the next one" operations, so you never touch its internal array, nodes, or indexes.

With external iteration the caller drives the loop and pulls elements one by one (while (it.hasNext()) ...). With internal iteration the caller hands a function to the collection (forEach { ... }) and the collection runs the loop, pushing each element into that function.

The cursor can be left pointing at the wrong place, so elements get skipped or repeated. Libraries pick a policy: fail fast with an error, iterate a snapshot taken when the iterator was created, or allow a "weakly consistent" walk that may or may not see later changes.

The iterator owns the position, not the collection. If the collection stores a single "current index" field, only one traversal can run at a time — nested loops, two threads, or two callers stepping through the same collection will fight over that one position.

The loop looks identical, but each next() may do real I/O. So the iterator now owns a resource that must be closed, can fail halfway through, is usually single-pass, and hides per-element cost — a plain-looking loop can issue thousands of network or disk requests.

Command turns a request into an object. The command holds what to do plus the data needed. The invoker (button, queue, scheduler) just calls execute() without knowing the receiver — the object that actually performs the work.

Add an undo() method next to execute(). Each executed command is pushed onto an undo stack. Undo pops it, calls undo(), and pushes it onto a redo stack. The command must remember whatever it needs to restore the previous state.

Wrap the child commands in one macro (composite) command that implements the same interface. Its execute() runs children in order; if one fails, it undoes the already-executed children in reverse order and rethrows, so the history sees one entry that either fully applied or not at all.

A closure captures a call to run later, which covers the simple case. Prefer a command object when you need more than one operation on it (undo, describe, merge), or when the request must be serialized, inspected, logged, or persisted — a closure is an opaque blob.

The command must be self-contained and serializable — all inputs captured, no live references — and its effect must be safe to apply more than once, because queues normally deliver at-least-once. It also needs a version so old stored commands still parse.

It lets one object behave differently as its internal condition changes. Each condition becomes a small class holding the behavior for that situation, and the main object forwards calls to whichever one is current — so no giant if/else.

Same shape, different purpose. With Strategy the caller chooses one interchangeable algorithm and it normally stays put. With State the object swaps its own behavior as its lifecycle advances, and the states know which state comes next.

If states set the next state, each state is self-contained but the whole map is scattered across classes. If the context decides, the map lives in one readable place but the context grows. Either way, funnel every change through one transition method.

Switch to a table when there are many states and events and the rules matter more than the code: a table is one page you can read, diagram, and validate. You lose the ability to write rich, typed, per-state behavior easily.

Store a stable code for the state, not the object, and rebuild the state object when loading. Decide transitions in memory, commit the new state, then perform outside effects afterwards — retried safely so a repeat does not charge twice.

Chain of Responsibility links several handler objects in a sequence. The sender passes a request to the first handler; each one either handles it or forwards it onward. The sender never knows which handler ultimately responds.

Each handler tests whether the request is its business. In a pure chain the first competent handler processes it and stops; in a broadcast chain handlers may act and still forward, so several contribute. The contract must say which it is.

Wrong order can let a broad handler swallow requests meant for a specific one, or let a step run before its prerequisite (e.g. authorization before authentication). Fix it by owning order in one explicit, tested place instead of leaving it implicit.

Classic Chain of Responsibility passes the request forward until one handler takes it. Middleware instead receives a next function, so it runs code before and after the rest of the chain — enabling timing, error wrapping, and response rewriting on the way back.

Nothing guarantees a handler matches, so a request can be silently dropped — no result, no error, no log. Always define the end of the chain: a default handler, an explicit error, or a result type that forces the caller to deal with 'nobody handled it'.

Visitor puts an operation over a set of object types into a separate 'visitor' object instead of inside those types. Each element has an accept method that calls back the right visit method. You can add new operations without editing the element classes.

Double dispatch means the method that runs depends on the runtime types of two objects. Most languages only dispatch on one (the receiver). Visitor chains two such calls: element.accept(v) picks by element type, then v.visit(this) picks by visitor type.

Visitor gathers one operation across all element types into one class, so a new operation is a new class and no edits elsewhere. But a new element type means adding a visit method to the visitor interface, which breaks every existing visitor. Use it when types are stable and operations grow.

Traversal can live in the element's accept (elements recurse into children), in the visitor (each visit method recurses), or in a separate walker object. Putting it in the visitor gives the most control — you can change order, skip subtrees, or stop early.

Adding a method to a published interface breaks everyone implementing it. Give the new visit method a default implementation (or provide an abstract base visitor with defaults) so old code still compiles — but then a visitor that never handles the new node fails silently instead of at compile time.

Mediator defines one object that encapsulates how a group of objects interact. Instead of each object calling the others directly, they all talk to the mediator. That turns tangled many-to-many links into simple one-to-many links.

Observer broadcasts an event to subscribers the sender does not know; it carries no rules about who reacts. Mediator is a named object that knows all participants and decides what each should do. Observer is notification; Mediator is coordination.

Every new interaction rule gets added to the one mediator, so it grows a branch per case until it knows everything and everyone edits it. Fixes: split by cohesive interaction area, keep it routing-only with logic in colleagues, and use typed handlers instead of one giant switch.

Introduce a mediator when classes hold references to many siblings, one rule change forces edits in several of them, and reuse is impossible because each object hard-references the others. Skip it when only two objects talk or reactions are independent broadcasts.

The same star topology appears as orchestrators, workflow/saga coordinators, message brokers, API gateways, and enterprise service buses. Across services the centralizer also becomes an availability, scaling, and ownership bottleneck — not just a code-cohesion problem.

Memento saves a snapshot of an object's internal state so it can be put back later (for example, undo) without exposing that object's internals. The originator makes and restores snapshots, the memento holds the saved state, and the caretaker stores mementos without looking inside them.

The memento offers two views: a narrow public one (basically just a handle, maybe a label or timestamp) used by the caretaker, and a wide one exposing the actual state that only the originator can reach — via a nested class, package/internal visibility, a private interface, or a language-specific friend mechanism.

Memory grows as snapshot size times history depth. Bound it by capping the number of snapshots (a ring buffer), snapshotting only at meaningful boundaries instead of every change, storing deltas instead of full copies, sharing unchanged parts between snapshots, and spilling older snapshots to disk.

Snapshots save the whole state and restore it wholesale — simple and always correct, but costly when the state is large. Reversible operations save just the action and how to invert it — cheap in memory, but every operation needs a correct inverse. Many systems use commands and let a command carry a small memento for the part it cannot invert.

Snapshots only restore state the object owns in memory. Anything that escaped — files written, messages sent, remote calls made — is not rolled back by restoring a snapshot. Those need explicit compensating actions, and live resources such as connections should be rebuilt on restore rather than captured.

Interpreter gives a small language a class per grammar rule, each with an interpret operation. A sentence is turned into a tree of these objects, and evaluating the tree executes the sentence. Best for small, stable mini-languages.

Every grammar rule costs a class, so a big grammar means dozens of tiny classes that are hard to keep consistent, and the pattern gives you no parsing help. For real languages use a parser generator or parser combinators plus a compiled evaluator.

AbstractExpression declares interpret(context). Terminals are leaves like literals and variables. Non-terminals hold child expressions and combine their results. Context carries variable values and input needed while evaluating. The client builds the tree and calls interpret on the root.

Put interpret() on the nodes when the language has few operations and you expect to add new node types. Use a Visitor when you need many operations over the same tree — evaluate, print, type-check, optimize — because each becomes one class instead of a method on every node.

It shows up wherever rules are data: search and filter expressions, feature-flag targeting, pricing and validation rules, query builders, and simple matchers. It differs from Command (one request as an object), Strategy (one swappable algorithm), and Composite (structure only, no grammar meaning).

Null Object is a real object that implements an interface but does nothing (or returns harmless defaults). You hand it out instead of a null/nil reference, so calling code can just call methods without checking for absence first.

Null Object hides absence behind a do-nothing object so callers just call methods. Optional/Maybe shows absence in the type and forces the caller to handle it. Hide it when a harmless default exists; show it when the caller must decide.

Return the neutral value for how the caller uses the result: nothing for commands, 0 for sums, empty string or empty collection, false for permission checks, and another null object for object-returning methods. Methods asking about identity or existence have no neutral answer.

They used do-nothing objects where the work was actually required, so missing configuration looked like success. Use null objects only when doing nothing is a valid outcome; elsewhere fail fast at startup, and make no-op paths visible in logs and metrics.

Special Case is the general form: named subclasses for each abnormal case (unknown, missing, suspended) with tailored behavior. Null Object is the degenerate one where the case is "absent" and the behavior is nothing. You outgrow the null object when the different absences need different behavior.