Template Method pattern in LLD - System Design Exercise

Design: Template Method Pattern Implementation

Design and implement the Template Method pattern focusing on class structure and method overriding. Out of scope are specific application domains or UI implementations.

Functional Requirements

FR1: Define a base algorithm structure with fixed steps.

FR2: Allow subclasses to override certain steps without changing the algorithm's structure.

FR3: Ensure the algorithm steps are executed in a specific order.

FR4: Support reuse of common code in the base class.

FR5: Allow easy extension for new variations of the algorithm.

Non-Functional Requirements

NFR1: The base algorithm structure must remain unchanged by subclasses.

NFR2: Subclasses can only override specific steps, not the entire algorithm.

NFR3: The design should promote code reuse and avoid duplication.

NFR4: The solution should be easy to understand and maintain.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Abstract base class defining the template method and abstract steps

Concrete subclasses overriding specific steps

Hook methods for optional steps

Method visibility (protected/private) to control overriding

Design Patterns

Template Method pattern

Inheritance and polymorphism

Hook methods

Open/Closed Principle

Reference Architecture

  +---------------------+
  | AbstractAlgorithm   |
  |---------------------|
  | + templateMethod()   |  <--- fixed algorithm steps order
  | # step1()           |  <--- abstract step
  | # step2()           |  <--- abstract step
  | # hook()            |  <--- optional step
  +----------+----------+
             |
             |
  +----------+----------+
  | ConcreteAlgorithmA   |
  |---------------------|
  | + step1() override  |
  | + step2() override  |
  | + hook() override?  |
  +---------------------+

  +---------------------+
  | ConcreteAlgorithmB   |
  |---------------------|
  | + step1() override  |
  | + step2() override  |
  +---------------------+

Components

AbstractAlgorithm

Abstract class or interface

Defines the template method with fixed step order and declares abstract steps to be implemented by subclasses.

ConcreteAlgorithmA

Subclass

Implements specific steps of the algorithm by overriding abstract methods.

ConcreteAlgorithmB

Subclass

Another variation implementing different steps.

Request Flow

1. Client calls templateMethod() on an instance of a concrete subclass.

2. templateMethod() executes steps in fixed order: step1(), step2(), hook().

3. Each step calls the subclass's overridden method if provided.

4. Optional hook() method can be overridden or left empty.

5. Algorithm completes after all steps execute in order.

Database Schema

Not applicable for this design pattern focused on class structure and behavior.

Scaling Discussion

Bottlenecks

Adding many subclasses can increase maintenance complexity.

If steps need to change order dynamically, pattern is less flexible.

Overriding too many steps may lead to duplicated code across subclasses.

Solutions

Use composition or strategy pattern if dynamic step order is needed.

Extract common code into helper methods to reduce duplication.

Limit subclass responsibilities to only necessary step overrides.

Document template method clearly to avoid misuse.

Interview Tips

Time: Spend 10 minutes explaining the pattern concept and problem it solves, 15 minutes designing the class structure and method flow, 10 minutes discussing pros, cons, and scaling.

Explain fixed algorithm structure with customizable steps.

Show how inheritance and method overriding enable reuse.

Discuss how template method enforces step order.

Mention optional hooks for flexibility.

Highlight benefits like code reuse and easier maintenance.

Discuss limitations and when to use alternative patterns.