Template Method Pattern (TypeScript)

Intent

Define a stable algorithm skeleton in a base class and let subclasses override selected steps or hooks without changing the overall order.

When to use

• Import pipelines (CSV/PDF/DOC) with shared sequence but different parsing.
• ETL workflows with common stages and varied implementations.
• Report generation pipelines with shared fetch/deliver steps.
• Payment processing flows (validate -> authorize -> capture) with varied details.
• Background job runners with consistent lifecycle hooks.
• Notification rendering pipelines with per-channel formatting.
• Parsing/normalization flows with shared structure.
• ML/data-prep pipelines that share ordering but vary transforms.

When NOT to use

• You need runtime swapping between algorithms (Strategy).
• Behavior changes due to lifecycle/state transitions (State).
• You need queue/log/undo or remote execution of requests (Command).
• Variations are data-only parameters or configuration.
• Only a couple of variants with low duplication; a shared function is clearer.
• Excessive subclassing would create a fragile base class.
• The base class would need too much IO knowledge.
• The workflow is not stable enough to justify a skeleton.

Mental model

Base class owns the workflow and ordering; subclasses override variable steps; hooks provide optional extension points.

Recommended TS shapes

• Abstract base class with run() template method calling protected steps.
• Hooks as protected beforeX()/afterX() no-ops.
• "Final-ish" enforcement: public run() calls a private doRun(); subclasses override only steps.

Example 1: Document import pipeline (CSV/DOC/PDF)

Steps: load -> parse -> normalize -> validate -> persist -> report. Base provides normalization/validation.

Example 2: Payment processing flow (Card/BankTransfer)

Steps: validate -> authorize -> capture -> receipt, with a hook around authorize.

Example 3: Report generation (Summary/Detailed)

Steps: fetch -> compute -> format -> deliver. Base handles fetch + deliver; subclasses override compute/format.

Testing strategy (pragmatic)

• Base-class contract tests using a fake subclass.
• Per-subclass tests for overridden steps.
• Verify ordering with an in-memory trace.
• Ensure hooks are optional and no-op by default.

Common pitfalls

• Too many steps making the base hard to understand.
• Overriding the template method itself.
• Calling overridable methods from constructors.
• Leaking shared mutable state across subclasses.
• Fragile base class changes that break subclasses.
• Mixing selection logic with template orchestration.
• Tight coupling to IO inside the base class.
• Too many tiny subclasses that differ only by data.
• LSP surprises when subclasses "disable" default steps.
• Using Template Method when Strategy would be simpler.

Checklist for refactors

• Identify duplicated workflows across implementations.
• Define clear step boundaries and names.
• Move the skeleton to a base class.
• Make variable steps protected or abstract.
• Add hooks for optional behavior.
• Migrate variants one by one.
• Remove client conditionals once subclasses exist.
• Add ordering tests and per-variant tests.

Output expectations

When invoked, produce: base abstract class, clear step methods + hooks, 2-4 concrete subclasses, and tests/examples demonstrating ordering and overrides.