Template Method
Template Method fixes an algorithm's skeleton in a base method while subclasses override specific steps. It centralizes shared structure and reduces duplication, trading runtime flexibility for inheritance-based reuse.
Template Method is a behavioral pattern that defines the overall structure of an algorithm in a single method, while letting subclasses override specific steps without changing the algorithm's shape. It captures the invariant parts of a process once in a base class and leaves the variable parts as overridable hooks. This is inheritance-based code reuse driven by the Hollywood principle: don't call us, we'll call you.
How It Works
An abstract base class defines a template method that lays out the sequence of steps as calls to other methods. Some of those methods are concrete and shared; others are abstract primitive operations that subclasses must implement, or hooks with default behavior that subclasses may optionally override. The template method itself is usually marked final or non-overridable so the high-level flow stays fixed. Subclasses fill in the gaps, customizing the algorithm without seeing or altering its overall control flow.
The result is that common structure lives in one place and only the genuinely varying steps are duplicated, reducing repetition across related implementations.
When to Use It
Use Template Method when several classes share the same overall algorithm but differ in particular steps, when you want to control the points at which subclasses can extend behavior, or when you find yourself duplicating a multi-step process with small variations. It is common in frameworks, where the framework owns the flow and applications supply the specifics, and in operations like parsing, report generation, and lifecycle callbacks.
Trade-offs
The pattern relies on inheritance, which couples subclasses tightly to the base class and limits flexibility to a single parent. A change to the template's step contract can ripple through all subclasses. Too many hooks make the base class hard to understand. Because the structure is fixed at compile time, you cannot recompose it at runtime the way composition allows; Strategy offers that flexibility at the cost of more objects.
Related Patterns
Strategy achieves variation through composition rather than inheritance, swapping whole algorithms at runtime, while Template Method varies individual steps statically; a common refactoring replaces Template Method with Strategy when more flexibility is needed. Factory Method is a specialization of Template Method used to create objects within an algorithm. Decorator changes behavior by wrapping rather than subclassing. The pattern is pervasive in frameworks, where the framework owns the overall control flow and your subclass supplies the specifics; servlet lifecycle methods, test setup and teardown hooks, and abstract base classes in standard libraries are all template methods inviting you to fill in the blanks.
Example
A data importer defines importData as: open source, validate, transform, save, close. The base class implements open, save, and close once and marks importData final so the sequence cannot be altered. CsvImporter and JsonImporter override only the abstract validate and transform steps, while an optional onError hook has a default empty body that subclasses may override. The import flow is guaranteed consistent across formats, and adding an XML importer means overriding two steps rather than rewriting the pipeline. The same skeleton appears in report generators that fix the header-body-footer order while subclasses fill each section, in build tools that run compile, test, and package in a fixed sequence, and in HTTP request handlers that authenticate, dispatch, and serialize uniformly while leaving the business step to the concrete handler.