Template Method
Template Method fixes the order of a workflow in a base operation while allowing selected steps to vary. Subclasses specialize hooks without rewriting the whole algorithm.
What you’ll understand
- Template Method fixes the order of a workflow in a base operation while allowing selected steps to vary. Subclasses specialize hooks without rewriting the whole algorithm.
- The base render method calls an overridable format hook and then appends the shared footer.
- Evaluate the tradeoff: Inheritance ties customizations to the base workflow. Strategy is often better when the varying step should be switched independently at runtime.
Useful first: Classes and Objects
The idea and when to recognize it
Template Method fixes the order of a workflow in a base operation while allowing selected steps to vary. Subclasses specialize hooks without rewriting the whole algorithm.
- Requirement: A report always loads values, formats them, and adds a footer, but formatting can be plain or bracketed.
- Change to anticipate: Customize formatting while preserving the required footer and step order.
- Design goal: The base render method calls an overridable format hook and then appends the shared footer.
Start with the concrete problem
A report always loads values, formats them, and adds a footer, but formatting can be plain or bracketed.
Customize formatting while preserving the required footer and step order.
| Direct implementation | Revised design |
|---|---|
| Overriding the entire rendering algorithm accidentally drops a mandatory footer. | The base render method calls an overridable format hook and then appends the shared footer. |
| The baseline case can hide the problem. Compare the extension and boundary fixtures before accepting this design. | Inheritance ties customizations to the base workflow. Strategy is often better when the varying step should be switched independently at runtime. |
Responsibilities and contracts
The base render method calls an overridable format hook and then appends the shared footer.
- Report: Fixes workflow order. Public operations: render(values), format(values)
- BracketReport: Overrides one formatting hook. Public operations: format(values)
Read the design
Select a participant to inspect its responsibility and public operations. Follow the labeled relationships; an arrow indicates direction, while the legend distinguishes ownership, substitution, and temporary use.
Preparing the design walkthrough…
Follow the interaction
Choose a supplied workload and compare the direct and revised implementations. Step through the same operation in both languages. Object values are recorded after each highlighted statement; previous steps remain unchanged.
Preparing the design walkthrough…
Implementation and expected output
Read the complete example alongside its input and expected output. The implementation selector changes the displayed program; the language selector preserves your current scenario and playback position.
Preparing the design walkthrough…
Try the idea in another setting
A data importer can preserve validate-transform-save ordering while specializing its parsing step.
- Name the new client contract before adapting the example.
- Identify which state belongs to each object and who controls its lifetime.
- Write one normal case and one boundary case before extending the design.
Tradeoffs and interview takeaways
Inheritance ties customizations to the base workflow. Strategy is often better when the varying step should be switched independently at runtime.
Common mistake: Overriding the entire rendering algorithm accidentally drops a mandatory footer.
- Explain the choice: The base render method calls an overridable format hook and then appends the shared footer.
- Challenge your choice: Inheritance ties customizations to the base workflow. Strategy is often better when the varying step should be switched independently at runtime.
- Describe a requirement that would make the simpler implementation sufficient.
Design challenge and knowledge check
Preparing the design walkthrough…