Compare Strategy with Template Method and with Bridge: what does each vary, by what mechanism, and how do you choose between them?

## Vocabulary first - **Inheritance** — a subclass reuses and specializes a base class; the binding is fixed when the object is created and cannot change afterwards. - **Composition** — an object holds a reference to a collaborator and delegates; the collaborator can be chosen or replaced at runtime. - **Hook method** — an abstract or overridable method called by a base-class algorithm at a defined point. - **Combinatorial explosion** — when two independent axes of variation are modeled by subclassing, you need M × N classes (`WindowsCircle`, `LinuxCircle`, `WindowsSquare`, …). ## Template Method *Intent*: define the skeleton of an algorithm in an operation, deferring some steps to subclasses; subclasses redefine steps without changing the algorithm's structure. ``` abstract class Importer { final run(source) { // the invariant skeleton, deliberately not overridable raw = read(source) // hook parsed = parse(raw) // hook validate(parsed) // shared, fixed persist(parsed) // hook } protected abstract read(s); protected abstract parse(r); protected abstract persist(p) } ``` *Use it when*: the sequence is genuinely invariant and worth enforcing, the variation is *within* steps, and you control the base class. It gives maximum code reuse of the skeleton with minimum boilerplate. *Costs*: the variant is chosen when you pick the class, so no runtime swapping; only one skeleton can be inherited (single inheritance in most languages); the base–subclass contract is implicit and easy to break — the *fragile base class* problem, where a change in the base silently breaks subclasses you can't see; subclasses can be tempted to override the skeleton itself; a subclass overriding a hook that the base calls during construction is a classic initialization bug; and testing a step usually means instantiating the whole subclass. *The Strategy equivalent ("prefer composition")*: convert each hook into an injected collaborator — `Importer(reader, parser, persister)`. Now steps are independently testable and mixable, at the cost of more wiring. This is exactly why many codebases migrate Template Method → Strategy as the family grows. ## Strategy *Intent*: define a family of interchangeable algorithms behind one interface so the algorithm varies independently of clients. Differences from Template Method that matter in practice: | | Template Method | Strategy | |---|---|---| | Mechanism | Inheritance | Composition/delegation | | Bound | Compile time (class choice) | Runtime (injected value) | | Varies | Steps inside a fixed skeleton | The whole operation | | Reuse of skeleton | Automatic (base class) | Manual (context or a shared collaborator) | | Testability of a variant | Needs the subclass + base | Variant alone | | Multiple axes | Combinatorial subclasses | Multiple injected strategies | | Extensible by others | Only by subclassing your base | By implementing a published interface | *Hybrid*: a Context that owns the skeleton and delegates each step to an injected strategy is Template Method's intent implemented with Strategy's mechanism — common and usually the better default when the number of variants grows. ## Bridge *Intent*: decouple an abstraction from its implementation so the two can vary independently. ``` abstract class Shape(renderer: Renderer) { abstract draw() } // Abstraction class Circle(r: Renderer): Shape(r) { draw() = r.drawCircle(...) } // RefinedAbstraction interface Renderer { drawCircle(...); drawRect(...) } // Implementor class SvgRenderer / CanvasRenderer implements Renderer // ConcreteImplementor ``` Without Bridge you'd write `SvgCircle`, `CanvasCircle`, `SvgRect`, `CanvasRect` — M × N. With Bridge you write M + N. *How it differs from Strategy despite the similar picture*: - Strategy's context is typically **one class** with a **pluggable algorithm**; Bridge's abstraction is itself a **hierarchy** that grows alongside the implementor hierarchy. - Strategy's implementations are *alternative solutions to the same task*, often switched per call/request. Bridge's implementors are *platform/backend layers* usually fixed for the lifetime of the object. - Strategy interfaces are usually one operation; Bridge implementors expose a primitive-operations API the abstraction composes into higher-level behavior. - Strategy is behavioral (how work gets done); Bridge is structural (how types are composed). ## Choosing 1. Is the *sequence* fixed and only steps vary, and do you own and control the base class with few variants? → **Template Method** (or its composed hybrid). 2. Does the *whole operation* vary, must the choice be made at runtime/config/tenant, or do you want outside code to add variants? → **Strategy**. 3. Are there *two independent axes* (domain concept × backend/platform) that would cross-multiply into subclasses? → **Bridge**. 4. Is the variation a *value* rather than an algorithm? → a lookup table, not a pattern. Also in the neighborhood: **Decorator** wraps a strategy to add behavior (caching, metrics, retries) while keeping the interface; **Chain of Responsibility** tries handlers in order rather than selecting one; **State** looks like Strategy but is lifecycle-driven; **Visitor** varies operations over a fixed set of types instead of varying one operation. A final practical note: these are communication labels. What matters in a design discussion is naming *which axis varies*, *when it is bound*, and *who is allowed to add a variant* — the pattern name is shorthand for those three answers.