Skip to main content
computer-science engineering-and-technology military-sciences statistics

Template method

Description

Template-method fixes the overall shape of an algorithm — the sequence of steps and the contract between them — while letting specific steps be overridden by specialized implementations. The base class (or the canonical procedure) defines the skeleton; concrete subclasses (or specific recipes) supply the hooks. The defining property is that the structure is fixed: regardless of which hooks are plugged in, the order, the invariants, and the contract between steps stay the same. The contrast with strategy is granularity. Strategy swaps the entire algorithm; template-method swaps individual steps inside an otherwise-fixed algorithm. The contrast with decorator is location: decorator stacks behaviors around a method call; template-method exposes specific seams inside the method’s body. Cross-domain: a culinary recipe is template-method (sequence fixed, ingredients vary); military doctrine is template-method (doctrine fixed, tactics vary); assembly-line manufacturing is template-method (steps fixed, station-specific operations vary); academic experimental protocols are template-method (design fixed, parameters vary).

Triggers

User-initiated: User says “I want users to customize step X but not the overall shape” or “subclasses should override these specific methods.” Vocabulary cues: “skeleton,” “hooks,” “extension points,” “override only step X,” “the framework decides the shape.” Agent-initiated: Agent notices several near-duplicate algorithms with the same overall shape but different inner steps. Candidate inference: “factor the shared shape into a template-method; expose the differing steps as hooks.” Situation-shape signals: Several implementations doing roughly the same thing in roughly the same order. Boilerplate at the top and bottom of methods that differ only in their middle. Framework-style code where the framework should drive the lifecycle and the application should fill in specific behavior.

Exclusions

  • The “skeleton” is the part that should vary — if real use cases want to change the order or omit/add steps, template-method is the wrong primitive; strategy or composition is better.
  • Hooks need to call back into framework internals — if hooks need access to the framework’s internals to do their job, the abstraction is leaking and the template-method is overconstraining; rethink which parts are fixed.
  • The framework is too small — for a one-shot procedure with one specialization, template-method is over-engineering; just write the procedure.
  • Inheritance constraints conflict with other axes — classical template-method via inheritance binds you to OOP-style inheritance trees; if specializations need to vary along multiple orthogonal axes, the inheritance ceiling becomes a problem (composition / strategy is usually the recovery).

Structure

Internal structure of template-method: a table of its component slots and the concepts that fill them.

Relationships

Relationship neighborhood of template-method: a graph of the concepts it connects to and the concepts it is a part of.
  • doctrine — doctrines are template-methods at the level of named procedures; the doctrine fixes the skeleton, contextual judgment fills the hooks.
  • strategy — strategy and template-method are GoF’s pair of answers to “make this algorithm customizable” — different granularities, sometimes used together (a step inside a template-method might itself be a strategy).
  • stack-layer — template-method is a single-method stack-layer relative: the skeleton is one layer, the hooks are slots for layers above to supply specialized behavior.
  • surface — the hooks are the surface the framework exposes for extension; the skeleton is the load-bearing structure behind it.
  • uniformity-dividend — the fixed skeleton’s invariance is the source of the uniformity payoff; every specialization gets the framework’s guarantees because the skeleton holds.

Examples

GoF Template Method · computer-science

the OOP coinage; example was a framework hook for “what to do after a button click.”

Assembly lines · engineering-and-technology

the line fixes the sequence and pacing; each station’s specific work is the hook.
IRB-approved skeleton; per-study parameter choices fill the hooks.
The Gang of Four’s Design Patterns introduced Template Method as a behavioral pattern: a base class defines the algorithm’s skeleton in a non-overridable method, while specific steps in that skeleton are declared abstract or “hook” methods that subclasses override. The control flow lives in the base class; the variability lives in the subclass.The example instantiates the inversion-of-control move that gives Template Method its other common name, the Hollywood Principle (“don’t call us, we’ll call you”) — the framework calls into the subclass’s overridden steps at the framework’s chosen points, rather than the subclass driving the sequence. The structural shape recurs in test fixtures (setUp/tearDown around the user’s test method), web request lifecycles (middleware chain around the user’s handler), and the recipe / military-doctrine / assembly-line analogues already in the catalog: a fixed sequence with named slots where local variation is permitted.
the doctrine fixes the operation’s shape; tactical variation happens at specified hooks.
setUptest_*tearDown is template-method; the test framework owns the skeleton.
Django/Rails/Spring all use template-method (route → middleware → controller hook → render); the framework fixes the skeleton, the application supplies the controller hooks.