Strategy pattern in LLD - System Design Exercise

Design: Strategy Pattern Implementation

Design and implement the Strategy pattern for a simple context that can switch between different algorithms dynamically. Out of scope: complex UI integration or persistence.

Functional Requirements

FR1: Allow an object to change its behavior at runtime

FR2: Support multiple interchangeable algorithms or strategies

FR3: Enable adding new strategies without modifying existing code

FR4: Clients should interact with a common interface to use strategies

Non-Functional Requirements

NFR1: Design should follow Open/Closed Principle

NFR2: Strategy switching should be efficient with minimal overhead

NFR3: Code should be easy to understand and maintain

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

Key Components

Context class that uses a strategy

Strategy interface defining common behavior

Concrete strategy classes implementing different algorithms

Design Patterns

Strategy pattern for behavior encapsulation

Dependency Injection to provide strategies to context

Factory pattern to create strategy instances if needed

Reference Architecture

  +-----------------+       uses       +---------------------+
  |     Context     |----------------->|     Strategy         |
  |-----------------|                  |---------------------|
  | - strategy:Strategy|                | + executeAlgorithm() |
  | + setStrategy()  |                  +---------------------+
  | + performTask()  |                          ^
  +-----------------+                          |
           |                                   |
           |                                   |
  +-----------------+                +---------------------+
  | ConcreteStrategyA|                | ConcreteStrategyB    |
  |-----------------|                |---------------------|
  | + executeAlgorithm()|             | + executeAlgorithm() |
  +-----------------+                +---------------------+

Components

Context

Any OOP language

Holds a reference to a Strategy and delegates behavior execution to it

Strategy Interface

Any OOP language interface or abstract class

Defines a common method for all supported algorithms

Concrete Strategies

Any OOP language classes

Implement different algorithms or behaviors following the Strategy interface

Request Flow

1. Client creates a Context object

2. Client creates a Concrete Strategy object

3. Client sets the Concrete Strategy on the Context using setStrategy()

4. Client calls performTask() on Context

5. Context delegates the call to the current Strategy's executeAlgorithm() method

6. Strategy executes its specific algorithm and returns the result

7. Context returns or uses the result as needed

Database Schema

Not applicable for this design pattern as it focuses on behavior encapsulation in code.

Scaling Discussion

Bottlenecks

Too many strategies can make management complex

Switching strategies frequently may add overhead

Strategies tightly coupled to context can reduce flexibility

Solutions

Use a Factory or Registry to manage strategy instances

Cache or reuse strategy instances when possible

Keep strategies stateless or minimize shared state to improve reusability

Interview Tips

Time: Spend 5 minutes explaining the problem and requirements, 15 minutes designing the pattern with examples, and 5 minutes discussing scaling and trade-offs.

Explain the problem of changing behavior dynamically

Describe how Strategy pattern encapsulates algorithms

Show how Open/Closed Principle is followed

Discuss how client interacts only with context and strategy interface

Mention benefits like easier testing and maintenance

Talk about potential overhead and how to mitigate it