Template Method Pattern
Define the skeleton of an algorithm in a base class, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.
Template Method = a tax form. The IRS defines the steps (income, deductions, calculate, sign) but you fill in YOUR specific numbers. The skeleton is fixed; the blanks are yours to override.
The base class implements the algorithm's invariant steps and declares abstract or hook methods for the variable steps. Subclasses override hooks without redefining the overall flow. Examples: data mining framework (openFile(), parseData(), analyzeData(), generateReport() — open and report are fixed; parse and analyze are abstract); JUnit's test lifecycle (setUp, test, tearDown — the skeleton is fixed, test methods are abstract).
Template Method is inheritance-based; Strategy is composition-based. Template Method is appropriate when the algorithm skeleton is the primary value and variations are small customizations within a known structure. The downside: it can lead to deep class hierarchies if there are many subclasses, and the Hollywood Principle ('don't call us, we'll call you') makes flow harder to follow. The 'hook' method (a concrete no-op method that subclasses can optionally override) vs 'abstract step' (mandatory override) is a design decision — hooks provide optional extension points without requiring every subclass to implement every step. Template Method appears in every framework: servlet lifecycle (init, service, destroy), Spring's JdbcTemplate (execute wraps connection management; the query logic is provided by the caller as a callback — a functional Template Method).
Template Method is my pattern when I want subclasses to plug into a fixed algorithm without rewriting it. My DataImporter base class defines import() which calls validate(), transform(), load() in sequence, wrapping each in error handling and logging. Concrete classes like CSVImporter and JSONImporter override validate() and transform() only. The import orchestration never changes. I prefer this over Strategy when the variation is small relative to the fixed algorithm, and when the subclass relationship is genuinely 'is-a specialization'. For more varied algorithms, Strategy is more flexible.
Template Method enforces compile-time coupling via inheritance. If the hook methods change signatures, all subclasses must change. Prefer Strategy when the variation point may evolve independently of the skeleton.