Strategy Pattern

Overview

The Strategy pattern defines a family of interchangeable algorithms, puts each one in its own class behind a shared interface, and lets the client choose one at runtime. The code that uses the algorithm (the context) does not know which concrete strategy it holds.

It replaces growing if/else or switch blocks that select behavior by type. Adding a new behavior becomes adding a new class instead of editing tested code, which is the Open-Closed Principle in action.

When to use it

• You have several ways to do the same task: payment methods, pricing rules, sorting, compression, routing.
• A method contains a switch on a type flag that keeps growing.
• Behavior must be chosen or swapped at runtime based on configuration or user input.
• You want to test each algorithm in isolation.

Where it shows up in interviews

Where it is used in real software

Key terms

Strategy interface

The shared contract, for example PaymentStrategy.pay(amount).

Concrete strategy

One implementation, such as CardPayment or UpiPayment.

Context

The class that holds a strategy reference and delegates to it, such as Checkout.

Composition

The context has a strategy rather than inheriting behavior.

How to apply it

1. 1
   Find the varying behavior

   Identify the switch or if/else chain that selects an algorithm.

2. 2
   Define the interface

   Extract one method signature that every variant can implement.

3. 3
   Move each branch into a class

   Each case becomes a concrete strategy with its own dependencies and tests.

4. 4
   Inject the strategy

   Pass the strategy into the context through its constructor or a setter.

5. 5
   Select at the edge

   A factory or map chooses the strategy from input, keeping selection logic in one place.

Before and after

A checkout that supports card, UPI, and wallet payments

The context depends on an abstraction, and new behavior is added by extension. Selection still happens somewhere, but in one small factory instead of inside business logic.

Implementation

1interface PaymentStrategy {2  pay(amount: number): PaymentResult;3}4 5type PaymentResult = { success: boolean; fee: number; reference: string };6 7class CardPayment implements PaymentStrategy {8  constructor(private cardNumber: string) {}9  pay(amount: number): PaymentResult {10    const fee = amount * 0.029;11    return { success: true, fee, reference: `CARD-${this.cardNumber.slice(-4)}` };12  }13}14 15class UpiPayment implements PaymentStrategy {16  constructor(private upiId: string) {}17  pay(amount: number): PaymentResult {18    return { success: true, fee: 0, reference: `UPI-${this.upiId}` };19  }20}21 22class Checkout {23  constructor(private strategy: PaymentStrategy) {}24 25  setStrategy(strategy: PaymentStrategy) {26    this.strategy = strategy; // swap at runtime27  }28 29  complete(amount: number): PaymentResult {30    return this.strategy.pay(amount); // no idea which provider31  }32}33 34const checkout = new Checkout(new CardPayment("4111111111111111"));35checkout.complete(128);36checkout.setStrategy(new UpiPayment("user@bank"));37checkout.complete(128);

Complexity and performance

Trade-offs

Variants and related techniques

Common mistakes

• Strategies that need different parameters.

  Fix: Pass a shared context object or supply extra data through the strategy's constructor.

• Moving the switch into the context's constructor.

  Fix: Keep selection in a factory so the context stays closed to modification.

• Creating a strategy for a single algorithm.

  Fix: Wait until a second real variant exists (YAGNI).

Interview questions

Practice problems