mdadul Template Method
Purpose
Help the user decide whether Template Method is appropriate, then design and implement stable algorithm skeletons with controlled extension points for subclasses.
When To Use
- User asks to explain Template Method pattern.
- Multiple classes share the same high-level algorithm flow with minor step differences.
- Code duplication exists across subclasses or sibling classes for orchestration logic.
- Team needs to preserve algorithm order while allowing variation in certain steps.
- Runtime strategy swapping is not required and inheritance-based variation is acceptable.
Inputs
- Current algorithm flow and step boundaries.
- Common vs varying steps across implementations.
- Required extension points (abstract steps, default steps, hooks).
- Inheritance constraints and subclass count.
- Contract rules/invariants that must remain fixed.
Workflow
- Clarify the goal. Confirm whether the user needs conceptual guidance, architecture review, or implementation/refactor.
- Check applicability. Use Template Method when algorithm shape is stable and only step implementations vary.
- Identify algorithm skeleton. Break the process into ordered steps and mark fixed sequencing constraints.
- Design base class. Implement template method orchestrating step calls; make it non-overridable where language supports it.
- Classify step types. Mark steps as abstract (must override), default (may override), or hooks (optional empty extension points).
- Extract shared logic. Move duplicated common behavior into base class default steps.
- Implement concrete subclasses. Override required steps and optional customizations while preserving base invariants.
- Refactor clients. Replace conditional class-specific orchestration with polymorphic calls to template method.
- Validate behavior. Ensure algorithm order is preserved across subclasses and variations remain local to steps.
Decision Branches
- If behavior must switch dynamically at runtime per object/request: Prefer Strategy.
- If you need to package operations as objects for queueing/undo/history: Prefer Command.
- If only object creation varies inside a broader algorithm skeleton: Consider Factory Method as a template step.
- If subclassing burden becomes high or inheritance is constrained: Prefer composition-based alternatives.
- If template method has too many steps and grows fragile: Split into smaller templates or extract subordinate collaborators.
Output Contract
When responding, provide:
- A suitability verdict (Template Method or better alternative).
- Skeleton summary (ordered steps, invariants, extension points).
- Role mapping (Abstract Base, Template Method, Concrete Subclasses, Client).
- Incremental migration plan from duplicated algorithms to template base class.
- Minimal code sketch in the user's language showing abstract/default/hook steps.
- Validation checklist proving order stability and safe extensibility.
Quality Checks
- Template method defines algorithm order once in base class.
- Subclasses cannot bypass required invariants enforced by the template flow.
- Abstract/default/hook boundaries are explicit and documented.
- Shared logic is centralized; subclass duplication is minimized.
- Adding a new variant requires subclass implementation, not base flow edits.
- Tests verify both base invariants and subclass-specific step behavior.
Common Mistakes To Prevent
- Letting subclasses override template flow and break ordering guarantees.
- Making every step abstract and losing shared behavior benefits.
- Overusing hooks and creating unclear extension semantics.
- Forcing inheritance where composition would be simpler.
- Building giant template methods that are hard to evolve safely.
References
- Detailed guide: REFERENCE.md
- Worked examples: EXAMPLES.md