gof-template-method

One-line summary

Define the skeleton of an algorithm in a base method, deferring some steps to subclasses — letting subclasses redefine certain steps without changing the algorithm's structure.

When to use this skill

• Two or more classes follow the same overall procedure but differ in one or two steps (Beck's "Coffee and Tea both brew" example).
• A workflow has a fixed sequence but specific stages vary by use case (e.g., a parsing pipeline where the tokenize step differs per format).
• Cross-cutting framework hooks: a base class provides lifecycle methods, subclasses override the ones they care about (Spring's JdbcTemplate, JUnit's setUp / tearDown).

When NOT to use this skill

• The variation is the algorithm itself, not steps within a skeleton — that's gof-strategy.
• Only one step varies and the variation is small — a function parameter or lambda is simpler than a subclass.
• The base class becomes an inheritance choke point that prevents the subclass from doing anything outside the template — that's a sign the abstraction is too rigid.

Core content

A TemplateMethod is a (typically final or non-overridable) method on the base class that calls a sequence of steps, some implemented in the base, others abstract or "hook" methods that subclasses override.

base.run():
    step1()         # final, implemented in base
    step2Abstract() # abstract — subclass must provide
    step3Hook()    # default no-op — subclass may override
    step4()         # final, implemented in base

Three kinds of steps:

• Concrete — fully implemented in the base class.
• Abstract — subclass must implement.
• Hook — default behavior (often a no-op or sensible default); subclass may override.

The "Hollywood Principle" — "don't call us, we'll call you" — is the framework-level expression of this pattern. The base class calls the subclass's overrides at the right moments; the subclass doesn't call the base class to drive the workflow.

Decision heuristics

• Use when the skeleton is shared and the steps vary. If only one step varies, consider a function parameter instead of a subclass.
• Make the template method final (or non-overridable) so subclasses can't break the workflow.
• Distinguish abstract steps (must override) from hook steps (may override) — and document which is which.
• If subclasses keep needing to override more and more steps to do non-trivial work, the template is too rigid.

Anti-patterns

• Template Method where the "template" is a giant method with many overridable steps — the rigidity that makes Template Method valuable disappears.
• Overriding the template method itself in a subclass — defeats the purpose.
• Calling super.step1() from a subclass's overridden step — couples subclass to base internals.

See also

• gof-strategy — when the whole algorithm varies, not just steps within it.
• gof-factory — Factory Method is an instance of Template Method (the algorithm defers the choice of concrete type to a subclass).
• gof-kotlin-idioms — Kotlin's open / final defaults make Template Method explicit, and higher-order functions often beat subclass-based templates for one or two varying steps.

References

• Head First Design Patterns (2nd ed), Ch. 8 ("Encapsulating Algorithms: the Template Method Pattern") — canonical exposition with the Coffee/Tea example.