What are the main drawbacks and failure modes of the Template Method pattern, and how would you refactor away from it when they start to hurt?

## Where Template Method earns its keep A quick reminder so the criticism lands in context: a base type holds a fixed algorithm (the *template method*) and calls steps that subtypes override — abstract *primitive operations* (must override) and *hooks* (may override). It removes duplicated control flow and lets a framework own a lifecycle. That is real value; the problems below are about *scale and evolution*, not about the pattern being wrong. ## Failure mode 1 — the fragile base class problem Inheritance is *white-box reuse*: the subclass sees and depends on the base class's internals — which steps exist, in what order they are called, what state is set by the time each one runs, whether one step calls another. None of that is captured in a type signature, so: - Reordering two steps, or calling a step twice instead of once, can break subclasses while the code still compiles. - Adding a new **abstract** step to a released base class is an outright breaking change: every existing subclass stops compiling. - Even adding a *defaulted* hook can break behaviour if the default does something a subclass did not expect. - A base-class method that internally calls another overridable method creates *self-use* dependencies: an override changes behaviour the base class relies on. (This is why the classic guidance is "design and document for inheritance, or else prohibit it.") The blast radius grows with the number of subclasses — and if the base class is published to other teams or the public, you cannot even enumerate them. ## Failure mode 2 — rigidity and class explosion - **Bound at construction.** Choosing a variant means instantiating a specific subclass; you cannot change the step later on the same object. - **One axis only.** With single inheritance, two independent varying aspects (format × destination, retry policy × serialisation) force a subclass per combination: 3 × 3 = 9, and each new value multiplies again. - **No reuse of the step elsewhere.** The overridden method is welded to that hierarchy; another algorithm that needs the same formatting logic must duplicate it or inherit from an unrelated parent. - **Constructor coupling.** Subclasses must satisfy the base constructor, so base-class dependency changes ripple into every subclass's constructor. ## Failure mode 3 — comprehension and debugging cost Reading a three-level hierarchy means holding the composed method in your head across three files, resolving at each call whether *this* level or a lower one implements the step. Stack traces are dominated by base-class frames. "Yo-yo problem" is the classic name: you scroll up and down the hierarchy to answer one question. Deep hierarchies also make refactoring risky because tooling cannot tell you which override relied on which ordering nuance. ## Failure mode 4 — Liskov Substitution Principle violations The skeleton is written against an implicit contract: *this step returns non-null, does not throw, does not mutate the collection I am iterating, is cheap enough to call in a loop, is safe to call twice*. An override that breaks any of these keeps the type check happy but corrupts the algorithm. Common examples: throwing `UnsupportedOperationException` from a step the skeleton always calls; caching in a hook that the skeleton invokes per row; a hook that calls the template method again (re-entrancy). ## Failure mode 5 — testing friction Testing one overridden step means constructing a subclass instance and satisfying whatever the base class needs (constructor args, framework context, sometimes a container). You cannot test the step as a pure function. This pushes teams toward heavier integration tests and mocking of base-class internals — a smell in itself. ## Refactoring out: Replace Inheritance with Delegation Mechanical, incremental recipe: 1. **Name the varying steps.** For each abstract/hook method, define a small interface with one method (or accept a function type). 2. **Add fields to the base class** for those collaborators, with defaults that call the existing overridable methods — behaviour unchanged. 3. **Convert one subclass at a time**: move the override body into an implementation of the new interface; construct the (now concrete) base class with that collaborator instead of extending it. 4. **Delete the abstract methods** once no subclass remains; make the class `final`/closed. 5. Along the way, **thread state explicitly**: what the override read from protected fields must now arrive as parameters or in a small immutable context object. This is the real work — and the point where you discover how much the hierarchy was leaking. Other escape hatches: - **Higher-order functions.** In languages with first-class functions, `runInTransaction(block)` or `export(rows, format = ::csv)` gives you the skeleton *and* the swappability with no types at all. - **Decorator / middleware chain.** If what subclasses actually add is before/after behaviour, a pipeline of wrappers composes better than a hierarchy and supports multiple independent concerns. - **Keep the skeleton, inject the steps.** Often the best answer is not either/or: keep the final template method for its ordering and cleanup guarantees, but have each step delegate to an injected collaborator. ## When *not* to refactor If variation is closed and small, all subclasses live in one module you own, the steps genuinely need internal state, and the algorithm is stable — the hierarchy is fine and cheaper than the interface ceremony. Refactor when you observe the actual symptoms: growing combinations, third-party subclasses blocking base-class changes, steps you want to test or reuse alone, or runtime selection requirements.