> ## Documentation Index > Fetch the complete documentation index at: https://agentconcepts.io/llms.txt > Use this file to discover all available pages before exploring further. # template-method > An algorithm skeleton with overridable steps: the outer structure is fixed, and specific steps (the "hook" points) can be customized by specialized implementations. 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](/concepts/doctrine) — doctrines are template-methods at the level of named procedures; the doctrine fixes the skeleton, contextual judgment fills the hooks. * [strategy](/concepts/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](/concepts/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](/concepts/surface) — the hooks are the surface the framework exposes for extension; the skeleton is the load-bearing structure behind it. * [uniformity-dividend](/concepts/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 the OOP coinage; example was a framework hook for "what to do after a button click." 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. `setUp` → `test_*` → `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.