Template Method

Template Method puts an algorithm's skeleton in one place and lets subclasses supply the steps that vary. It is the pattern that runs against the general advice to prefer composition — and it earns that exception in one specific situation: when the order of the steps is a correctness invariant that no variant may break.

The problem

Three importers — CSV, JSON, XML — each do the same four things in the same order.

class CsvImporter {
  run(file) {
    const rows = this.parse(file);
    validate(rows);        // must happen before normalising
    const clean = normalise(rows);
    persist(clean);
    audit(clean.length);
  }
}
// JsonImporter and XmlImporter: the same five lines, copied

Only parse differs. The other four lines are duplicated three times, and the duplication is not merely untidy — the order is a rule. Normalising before validating means invalid rows are silently coerced into valid-looking ones. A fourth importer written by someone who has not read the others will get it wrong eventually.

The pattern

class Importer {
  run(file) {                       // final — the sequence, owned here
    const rows = this.parse(file);
    validate(rows);
    const clean = normalise(rows);
    persist(clean);
    audit(clean.length);
  }
  parse(file) { throw new Error('subclasses must implement parse'); }
}

class CsvImporter extends Importer {
  parse(file) { return parseCsv(file); }
}

classDiagram
    class Importer {
        +run(file) void
        #parse(file)* Row[]
        #beforePersist(rows) void
    }
    class CsvImporter {
        #parse(file) Row[]
    }
    class JsonImporter {
        #parse(file) Row[]
        #beforePersist(rows) void
    }
    Importer <|-- CsvImporter
    Importer <|-- JsonImporter

A new format supplies parse and inherits the invariant. No subclass has the opportunity to reorder anything, which is the property Strategy cannot provide.

Abstract steps and hooks

Two kinds of extension point, and conflating them is a common design error.

An abstract step must be implemented. Not implementing it is a compile error or an immediate exception, which is what you want for parse — an importer that cannot parse is not an importer.

A hook has a default, usually doing nothing, and subclasses override it if they wish: beforePersist(rows). Hooks are how the base class offers optional extension without forcing every subclass to care.

The design mistake is making everything abstract, which forces every subclass to write empty implementations, or making everything a hook, which lets a subclass silently do nothing where something was required.

The cost, stated plainly

Inheritance is the strongest coupling available. A subclass depends on the base class's protected surface, its call order, and its internal assumptions. Changing the base class can break every subclass in ways the compiler will not catch — this is the fragile base class problem, and it is why the pattern deserves scrutiny rather than default use.

A subclass cannot be reused elsewhere. CsvImporter's parsing is trapped inside an importer. If something else needs to parse CSV, it either duplicates or instantiates an importer it does not want.

Testing requires the whole pipeline. Testing CSV parsing means running run() with validation, persistence and audit, or creating a test-only subclass.

One dimension only. If importers must vary by both format and destination, Template Method gives you format × destination subclasses. That is Bridge's problem, and Template Method has no answer to it.

The composition alternative, and when it is better

Most Template Methods are better as a function taking the varying step:

function runImport(file, parse) {
  const rows = parse(file);
  validate(rows);
  const clean = normalise(rows);
  persist(clean);
  audit(clean.length);
}

runImport(file, parseCsv);

The sequence is still in one place and still unbreakable, parseCsv is independently reusable and testable, and there is no inheritance. Prefer this whenever the language allows it.

The inheritance version earns its place when there are several related extension points that must agree with each other — a parse step, a validation rule and an error format that belong to the same format — and grouping them in one class is genuinely clearer than passing four functions. That is a real case, and it is narrower than the pattern's popularity suggests.

Check your understanding

Common mistakes

Using it merely to remove duplication. If the steps could legitimately be reordered, a shared function is better and cheaper.

Calling overridable methods from the constructor. Subclass fields are not initialised yet.

Making every step abstract. Subclasses write empty implementations to satisfy the base class.

Making every step a hook. A subclass silently does nothing where something was required.

Deep hierarchies. A template method inherited three levels down means the sequence is assembled from three files, and no reader can state it.

Trying to vary two dimensions. Format × destination is a product of subclasses; that is Bridge's problem.

A base class that grows shared helpers. It becomes a utility bag that every subclass depends on, and the coupling spreads beyond the sequence.

Practice

function reconcile(source) {
  const raw = source.fetch();
  const transactions = source.parse(raw);
  const matches = match(transactions, ledger);
  const discrepancies = flag(matches);
  writeReport(discrepancies);
}

Key takeaways

• Template Method puts an algorithm's skeleton in the base class and lets subclasses fill named gaps.
• Its unique contribution is an enforced ordering invariant — no variant can reorder or skip a step.
• Deduplication alone does not justify it. If a variant could legitimately reorder the steps, use a shared function.
• Distinguish abstract steps (must implement) from hooks (optional default). Making everything one or the other is a design error.
• Never call an overridable method from the constructor — the subclass's fields are not initialised yet.
• Costs: fragile base class coupling, steps that cannot be reused or tested alone, and one dimension of variation only.
• Prefer a function taking the varying step. Inheritance earns its place when several extension points must agree with each other.

Further reading

• Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1994).
• Robert C. Martin, Agile Software Development, Principles, Patterns, and Practices (Prentice Hall, 2002) — Template Method compared with Strategy.
• Leonid Mikhajlov and Emil Sekerinski, "A Study of the Fragile Base Class Problem" (ECOOP, 1998).
• Joshua Bloch, Effective Java, third edition (Addison-Wesley, 2018) — design for inheritance or prohibit it.
• Martin Fowler, Refactoring, second edition (Addison-Wesley, 2018) — form template method, and replacing it with delegation.