Template Method

The participants: one abstract class, three kinds of steps

Template Method is a one-class-hierarchy pattern. Everything lives in an abstract base class and its concrete subclasses:

• The template method — prepare() in HotDrink. It calls the steps in a fixed order and is marked final (or simply never overridden, in languages without final), so no subclass can tamper with the sequence.
• Invariant steps — boilWater() and pourInCup(). They're identical for every drink, so they're implemented once, concretely, in the base class.
• Abstract (primitive) steps — brew() and addExtras(). The base class declares them but can't implement them; every subclass must fill them in. Tea steeps a bag; Coffee drips grounds.
• Hooks (optional steps) — steps that come with a default implementation the subclass may override but doesn't have to. wantsExtras() returning true by default is a hook: Tea can leave it alone, but a BlackCoffee subclass could override it to return false and the skeleton would skip the extras step entirely.

abstract class HotDrink {
  // THE template method — the skeleton, written once, order fixed.
  prepare(): void {                    // (final in Java/C++; just don't override)
    this.boilWater();                  // 1 — same for everyone
    this.brew();                       // 2 — filled in by subclass
    this.pourInCup();                  // 3 — same for everyone
    if (this.wantsExtras()) {          // hook decides whether step 4 runs
      this.addExtras();                // 4 — filled in by subclass
    }
  }

  private boilWater()  { console.log("Boiling water"); }
  private pourInCup()  { console.log("Pouring into cup"); }

  protected abstract brew(): void;       // subclass MUST supply
  protected abstract addExtras(): void;  // subclass MUST supply

  protected wantsExtras(): boolean { return true; }  // hook: MAY override
}

class Tea extends HotDrink {
  protected brew()      { console.log("Steeping the tea bag"); }
  protected addExtras() { console.log("Adding lemon"); }
}

new Tea().prepare();   // parent runs the skeleton, Tea supplies steps 2 & 4

Inversion of control — not just "calling a helper"

It's easy to mistake this for ordinary method extraction — "so what, a method calls other methods?" The difference is the direction of control. When you extract a helper, your code decides when to call it. In Template Method, the base class decides when the subclass's code runs. Tea never calls boilWater() or arranges the sequence — it hands its two steps to the parent and the parent invokes them at the right moments. Control flows down from the skeleton into the filled-in steps. That's why frameworks are built on this shape: the framework owns the lifecycle and calls your overridden methods; you never call the framework's main loop.

The smell it cures: two near-identical methods

The tell-tale trigger is code review déjà vu: makeTea() and makeCoffee() are 12 lines each and 10 of those lines are identical. The classic refactoring is exactly this pattern — pull the identical lines up into a base-class template method, turn the two differing lines into abstract steps, and each subclass shrinks to just its unique bits. The shared logic now lives in one place, so a fix to boilWater() fixes every drink at once.

You already use this pattern every day

• JUnit / test frameworks — the runner's fixed lifecycle is setUp() → your test method → tearDown(). You override the steps; the framework owns the skeleton and calls them in order.
• Framework lifecycle hooks — React class components (componentDidMount, render), Rails controller callbacks (before_action), Android's onCreate/onStart: the framework runs a fixed sequence and invokes your overrides at published points.
• `java.util.AbstractList` — indexOf(), contains() and friends are written once against two abstract primitives, get(i) and size(). Implement those two and you inherit a whole working list API.
• Game loops — an engine's fixed init() → update() → render() cycle where your game overrides update() and render() but never reorders the loop.

Reach for Template Method when the shape is shared

• Several classes share an algorithm's shape but differ in a few steps — report generators that all fetch → transform → format → save, with only format varying; importers that differ only in parse.
• You keep seeing near-duplicate methods — two or more methods that are 90% identical. Pull the identical 90% into a template method and make the differing 10% abstract steps.
• You're a framework or library author defining extension points — you own the lifecycle (init → run → cleanup) and want users to customise published steps without ever being able to break the sequence.
• The step order is a real invariant — validation must happen before saving, water must boil before brewing. Locking the skeleton in a final method turns that rule from a convention into a guarantee.

When NOT to use it

• The steps vary wildly — if subclasses would override nearly every step, there's no real skeleton to share; you've just built an awkward inheritance tree. Extract whole interchangeable algorithms instead ([[strategy]]).
• Clients must swap the algorithm at runtime — inheritance is decided at compile time; a Tea can never become a Coffee mid-program. Strategy's composition lets you hand in a different behaviour on the fly.
• You'd need to vary more than one axis — a drink that varies by brew method and by serving style would need a subclass per combination. Composition handles multi-axis variation without the class explosion; see [[composition-vs-inheritance]].