Listen to this post
We want to abstract out a common theme from different cases that have different implementations of an algorithm.
Often systems/frameworks have a fixed workflow where the steps are always executed in a specific sequence, but the actions taken in each step vary by application context. Template method separates the common workflow from the individual steps it executes or organizes.
The Template Method may also contain common conditionals or other logic that does not vary by implementation.
Qualities and principles
The Template Method separates a common workflow from its varying implementations. The workflow is not redundant, and each implementation is about one version. All implementations are interchangeable. The interface of the Template Method is derived from the needs of clients. It encapsulates the workflow itself, the varying implementations (their number and nature), and which is currently active, making them open-closed.
The Template Method (Workflow) can be tested using a Mock implementation that can capture and record how it is used to ensure its methods are called correctly. Each implementation (WorkflowA, etc.) can have its own test; if protected methods are used, the test can be made a subclass.
Questions and concerns
The Template method is intended to abstract out the steps of an algorithm. If the steps are actually different algorithms, then the Template Method may have weak cohesion. If so, the step methods should delegate to behavioral objects rather than embedding the code in the Template.Thus the “single algorithm” would be the workflow itself. Many patterns have Template Method as part of their implementation; Decorator for example.