Strategy Pattern: Principles, Trade-offs & Examples

Strategy Pattern

Why This Matters

Think of the Strategy pattern like choosing a payment method at checkout. You don't change the checkout process—you just choose a different payment strategy (credit card, PayPal, bank transfer). The Strategy pattern does the same for code—it lets you choose different algorithms without changing the code that uses them.

This matters because algorithms change. You might start with a simple sorting algorithm, then need a faster one, or a stable one, or one that handles special cases. The Strategy pattern makes it easy to swap algorithms without changing the code that uses them. This follows the Open/Closed Principle—open for extension (new strategies), closed for modification (existing code).

In interviews, when someone asks "How would you refactor this code?", they're testing whether you understand the Strategy pattern. Can you identify when code has multiple algorithms that could be swapped? Can you encapsulate them as strategies? Most engineers can't. They use if/else statements and wonder why the code is hard to change.

What Engineers Usually Get Wrong

Engineers often think "Strategy pattern means always use strategies." But strategies add indirection. If you only have one algorithm and it's unlikely to change, direct implementation is fine. Use strategies when you have multiple algorithms that might change, or when you need to choose algorithms at runtime.

Engineers also confuse Strategy with Factory. Strategy is about choosing algorithms. Factory is about creating objects. They're different patterns for different purposes. Understanding the difference helps you choose the right pattern.

How This Breaks Systems in the Real World

A service was calculating discounts using if/else statements: if customer type is "premium", use premium discount; if "regular", use regular discount; etc. As more customer types were added, the if/else chain grew to 50 lines. It became hard to understand and test. The fix? Use Strategy pattern. Create a DiscountStrategy interface, with implementations for each customer type. Now adding a new customer type is just creating a new strategy, not modifying a long if/else chain.

Another story: A service was using different sorting algorithms based on data size. The logic was scattered across the codebase. When the team needed to change the algorithm selection logic, they had to modify code in 10 places. The fix? Use Strategy pattern. Centralize algorithm selection in one place. Now changing selection logic requires changes in only one place.

What is the Strategy Pattern?

Strategy Pattern provides:

• Algorithm encapsulation: Encapsulate algorithms in separate classes
• Interchangeability: Algorithms are interchangeable
• Runtime selection: Select algorithm at runtime
• Open/Closed Principle: Open for extension, closed for modification

Use cases:

• Sorting algorithms
• Payment processing
• Compression algorithms
• Validation strategies
• Discount calculations

Structure

Context
  └─ strategy: Strategy
  └─ execute() (uses strategy.algorithm())

Strategy (interface)
  └─ algorithm()

ConcreteStrategyA (implements Strategy)
  └─ algorithm()

ConcreteStrategyB (implements Strategy)
  └─ algorithm()

Examples

Payment Strategy

1 

Sorting Strategy

1 

Discount Strategy

1 

Common Pitfalls

• Too many strategies: Can become complex. Fix: Group related strategies
• Strategy selection: Hard to choose strategy. Fix: Use factory pattern
• Context bloat: Context becomes too large. Fix: Keep context simple
• Not using strategy: Using if-else instead. Fix: Use strategy pattern for multiple algorithms

Interview Questions

Beginner

Q: What is the Strategy pattern and when would you use it?

A:

Strategy Pattern defines a family of algorithms, encapsulates each, and makes them interchangeable.

Key characteristics:

• Algorithm encapsulation: Each algorithm in separate class
• Interchangeability: Algorithms are interchangeable
• Runtime selection: Select algorithm at runtime
• Open/Closed: Open for extension, closed for modification

Example:

1 

Use cases:

• Multiple algorithms: Different ways to do same thing
• Runtime selection: Choose algorithm at runtime
• Payment methods: Credit card, PayPal, etc.
• Sorting algorithms: Quick sort, merge sort, etc.

Benefits:

• Flexibility: Easy to add new algorithms
• Testability: Test each strategy independently
• Maintainability: Changes isolated to strategy classes

Intermediate

Q: Explain how the Strategy pattern works. How does it differ from if-else or switch statements?

A:

Strategy Pattern Structure:

1. Strategy Interface:

1 

2. Concrete Strategies:

1 

3. Context:

1 

Difference from If-Else:

If-Else (Not Strategy):

1 

Problems:

• Not extensible: Need to modify function for new types
• Violates Open/Closed: Closed for extension
• Hard to test: Can't test algorithms independently

Strategy Pattern:

1 

Benefits:

• Extensible: Add new strategies without modifying context
• Testable: Test each strategy independently
• Maintainable: Changes isolated to strategy classes

Senior

Q: Design a strategy system for a recommendation engine that uses different recommendation algorithms (collaborative filtering, content-based, hybrid). Handle algorithm selection based on user preferences, data availability, and performance requirements.

A:

1 

Features:

1. Multiple strategies: Different recommendation algorithms
2. Strategy selection: Select based on context
3. Performance metrics: Track algorithm performance
4. Hybrid approach: Combine multiple strategies

Failure Stories You'll Recognize

The If/Else Chain: A service was calculating discounts using if/else statements: if customer type is "premium", use premium discount; if "regular", use regular discount; etc. As more customer types were added, the if/else chain grew to 50 lines. It became hard to understand and test. The fix? Use Strategy pattern. Create a DiscountStrategy interface, with implementations for each customer type. Now adding a new customer type is just creating a new strategy, not modifying a long if/else chain.

The Scattered Algorithm Selection: A service was using different sorting algorithms based on data size. The logic was scattered across the codebase. When the team needed to change the algorithm selection logic, they had to modify code in 10 places. The fix? Use Strategy pattern. Centralize algorithm selection in one place. Now changing selection logic requires changes in only one place.

The Over-Engineered Strategy: A team used Strategy pattern for simple calculations that never changed. The abstraction added complexity without providing value. The code was harder to understand than a simple function. The fix? Use strategies only when algorithms might change or when you need to choose at runtime. For simple, stable algorithms, direct implementation is fine.

What Interviewers Are Really Testing

They want to hear you talk about Strategy as a tool for managing algorithm variations, not a rule to always follow. Junior engineers say "use Strategy pattern for algorithms." Senior engineers say "Strategy pattern encapsulates algorithms and makes them interchangeable. Use it when you have multiple algorithms that might change, or when you need to choose at runtime. Don't over-engineer—simple algorithms don't need strategies."

When they ask "How would you refactor this code?", they're testing:

• Can you identify when code has multiple algorithms?
• Do you know when to use Strategy vs direct implementation?
• Can you design strategies that are simple and maintainable?