Strategy pattern in LLD - Deep Dive

Overview - Strategy pattern

What is it?

The Strategy pattern is a way to change how a program behaves by swapping parts of its logic at runtime. It lets you define a family of algorithms or behaviors, put each one in its own class, and make them interchangeable. This means the program can pick the best behavior for the situation without changing its main code. It helps keep code clean and flexible.

Why it matters

Without the Strategy pattern, programs often become messy with many if-else or switch statements deciding what to do. This makes the code hard to read, change, or add new behaviors. The Strategy pattern solves this by separating behaviors into their own pieces, making it easy to add or change them without breaking the whole program. This leads to better software that adapts to new needs quickly.

Where it fits

Before learning the Strategy pattern, you should understand basic object-oriented programming concepts like classes, objects, and interfaces. After this, you can explore other design patterns like Factory or Decorator that build on similar ideas of flexibility and reuse. The Strategy pattern is a key step in learning how to design clean, maintainable software.

Mental Model

Core Idea

The Strategy pattern lets you swap interchangeable behaviors inside a program without changing its main structure.

Think of it like...

Imagine a remote control car that can change its driving mode by swapping different tires for different terrains. Each tire type is like a strategy that changes how the car moves without changing the car itself.

┌───────────────┐       uses       ┌───────────────┐
│   Context     │──────────────────▶│   Strategy    │
│ (main object) │                   │ (interface)   │
└──────┬────────┘                   └──────┬────────┘
       │                                   │
       │                                   │
       │                   ┌───────────────┴───────────────┐
       │                   │                              │
       ▼                   ▼                              ▼
┌───────────────┐   ┌───────────────┐             ┌───────────────┐
│ ConcreteStrategyA│ │ ConcreteStrategyB│           │ ConcreteStrategyC│
│ (one behavior)  │ │ (another behavior)│          │ (yet another)   │
└────────────────┘ └────────────────┘            └────────────────┘

Build-Up - 6 Steps

1

Foundation

Understanding behavior encapsulation

Concept: Learn that behaviors can be separated into their own classes to keep code organized.

Instead of writing all behaviors inside one big class with many conditions, we create separate classes for each behavior. Each class knows how to do one specific thing. This makes it easier to add or change behaviors without touching the main code.

Result

Behaviors are cleanly separated, making the code easier to read and maintain.

Understanding that behaviors can be isolated helps prevent messy code and prepares you to swap them easily later.

2

Foundation

Defining a common interface for behaviors

Concept: All behavior classes follow the same interface so they can be used interchangeably.

We create an interface or abstract class that defines the methods all behavior classes must have. This way, the main program can use any behavior class without knowing its details, as long as it follows the interface.

Result

The program can treat all behaviors the same way, enabling easy swapping.

Knowing that a shared interface allows different behaviors to plug into the same place is key to flexible design.

3

Intermediate

Context class uses strategy interface

🤔Before reading on: do you think the main program should know the details of each behavior or just use the interface? Commit to your answer.

Concept: The main class (context) holds a reference to the strategy interface and delegates behavior calls to it.

The context class has a variable that holds a strategy object. When it needs to perform a behavior, it calls the method on the strategy interface. The actual behavior depends on which concrete strategy is assigned.

Result

The context can change behavior by switching the strategy object it holds.

Understanding that the context only knows the interface and not the details allows behaviors to be swapped without changing the context.

4

Intermediate

Switching strategies at runtime

🤔Before reading on: do you think strategies can be changed while the program runs, or only before it starts? Commit to your answer.

Concept: The Strategy pattern allows changing the behavior dynamically by assigning a different strategy object to the context at runtime.

The context class provides a method to set or change the strategy object anytime. This means the program can adapt its behavior on the fly, like changing driving modes in a car.

Result

The program becomes flexible and can respond to different situations without restarting or rewriting code.

Knowing that behaviors can be swapped anytime makes programs more adaptable and powerful.

5

Advanced

Avoiding tight coupling with strategies

🤔Before reading on: do you think the context should create strategy objects directly or receive them from outside? Commit to your answer.

Concept: To keep the system flexible, the context should not create strategy objects itself but receive them from outside, often via dependency injection.

If the context creates strategies directly, it becomes tightly linked to them, making changes harder. Instead, strategies are created elsewhere and passed to the context. This allows easy swapping and testing.

Result

The system remains loosely coupled, easier to maintain and extend.

Understanding how to reduce dependencies between classes is crucial for scalable and testable software.

6

Expert

Strategy pattern in large-scale systems

🤔Before reading on: do you think the Strategy pattern can cause performance issues if overused? Commit to your answer.

Concept: In complex systems, using many small strategy objects can add overhead, so careful design and caching may be needed.

While the Strategy pattern improves flexibility, creating many small objects and switching them frequently can impact performance. Experts balance flexibility with efficiency by reusing strategies, lazy loading, or combining with other patterns like Flyweight.

Result

The system remains flexible without sacrificing performance.

Knowing the tradeoffs between flexibility and performance helps design robust real-world systems.

Under the Hood

The Strategy pattern works by holding a reference to an interface that defines a behavior. At runtime, the context object calls methods on this interface, which are implemented by concrete strategy classes. This indirection allows the behavior to be swapped without changing the context. Internally, this uses polymorphism and dynamic dispatch to select the correct method implementation.

Why designed this way?

It was designed to solve the problem of conditional logic scattered across code, which is hard to maintain. By encapsulating behaviors and using interfaces, the pattern promotes open/closed principle—open for extension, closed for modification. Alternatives like inheritance were less flexible because they fixed behavior at compile time.

┌───────────────┐
│   Context     │
│───────────────│
│ - strategy    │
│ + setStrategy()│
│ + execute()   │
└──────┬────────┘
       │ calls
       ▼
┌───────────────┐
│  Strategy     │  (interface)
│───────────────│
│ + execute()   │
└──────┬────────┘
       │
       │ implemented by
       ▼
┌───────────────┐   ┌───────────────┐   ┌───────────────┐
│ ConcreteStrategyA│ │ ConcreteStrategyB│ │ ConcreteStrategyC│
│ + execute()   │   │ + execute()   │   │ + execute()   │
└───────────────┘   └───────────────┘   └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does the Strategy pattern mean the context class must know all concrete strategies? Commit yes or no.

Common Belief: The context class must know and create all the concrete strategy objects itself.

Reality: The context only knows the strategy interface and receives concrete strategies from outside, often via injection.

Why it matters: If the context creates strategies directly, it becomes tightly coupled and hard to extend or test.

Quick: Is the Strategy pattern only useful for algorithms? Commit yes or no.

Common Belief: Strategy pattern is only for swapping algorithms or calculations.

Reality: It can be used to swap any behavior or policy, such as sorting, validation, or UI rendering.

Why it matters: Limiting the pattern to algorithms reduces its usefulness and leads to less flexible designs.

Quick: Does using many small strategy objects always improve performance? Commit yes or no.

Common Belief: More small strategy objects always make the system faster and cleaner.

Reality: Creating and switching many small objects can add overhead and reduce performance if not managed well.

Why it matters: Ignoring performance tradeoffs can cause slow or resource-heavy applications.

Quick: Can the Strategy pattern replace inheritance completely? Commit yes or no.

Common Belief: Strategy pattern removes the need for inheritance in all cases.

Reality: Strategy complements inheritance but does not replace it; sometimes inheritance is still the best choice.

Why it matters: Misusing Strategy to avoid inheritance can lead to overcomplicated designs.

Expert Zone

1

Some strategies may share common code; using abstract base classes for strategies can reduce duplication.

2

Changing strategies frequently at runtime may require thread-safety considerations in concurrent systems.

3

Combining Strategy with Factory pattern can automate strategy creation and selection based on context.

When NOT to use

Avoid Strategy pattern when behaviors are unlikely to change or when the added abstraction complicates simple code. For fixed behaviors, direct implementation or inheritance may be simpler and more efficient.

Production Patterns

In real systems, Strategy is used for payment methods, sorting algorithms, or feature toggles. It often pairs with dependency injection frameworks to manage strategy lifecycles and with configuration files to select strategies without code changes.

Connections

Dependency Injection

Strategy pattern often uses dependency injection to supply concrete strategies to the context.

Understanding dependency injection helps grasp how Strategy achieves loose coupling and easy swapping of behaviors.

Open/Closed Principle

Strategy pattern is a practical way to follow the open/closed principle by allowing behavior extension without modifying existing code.

Knowing this principle clarifies why Strategy pattern improves maintainability and scalability.

Biology - Evolutionary Adaptation

Like organisms adapting traits to survive in different environments, Strategy pattern allows software to adapt behaviors to different situations.

Seeing software design as adaptation helps appreciate the flexibility and survival advantage Strategy pattern provides.

Common Pitfalls

#1 Context creates concrete strategies directly, causing tight coupling.

Wrong approach:

class Context {
constructor() {
this.strategy = new ConcreteStrategyA();
}
execute() {
this.strategy.execute();
}
}

Correct approach:

class Context {
constructor(strategy) {
this.strategy = strategy;
}
setStrategy(strategy) {
this.strategy = strategy;
}
execute() {
this.strategy.execute();
}
}

Root cause:

Misunderstanding that the context should depend only on the strategy interface, not concrete implementations.

#2 Using Strategy pattern for behaviors that never change, adding unnecessary complexity.

Wrong approach:

Always wrapping simple fixed behavior in strategy classes even when no swapping is needed.

Correct approach:

Implement fixed behavior directly in the context or use simpler design without strategies.

Root cause:

Overgeneralizing the pattern without assessing actual need for flexibility.

#3 Not defining a common interface for strategies, causing inconsistent method names.

Wrong approach:

class ConcreteStrategyA {
run() { /*...*/ }
}
class ConcreteStrategyB {
execute() { /*...*/ }
}

Correct approach:

interface Strategy {
execute();
}
class ConcreteStrategyA implements Strategy {
execute() { /*...*/ }
}
class ConcreteStrategyB implements Strategy {
execute() { /*...*/ }
}

Root cause:

Ignoring the importance of a shared interface for interchangeable behaviors.

Key Takeaways

The Strategy pattern separates behaviors into interchangeable classes, making programs flexible and easier to maintain.

A shared interface allows the main program to use different behaviors without knowing their details.

Swapping strategies at runtime enables dynamic adaptation to changing conditions.

Loose coupling between context and strategies is essential for scalability and testability.

Understanding tradeoffs between flexibility and performance is key to using Strategy effectively in real systems.