The Strategy Pattern: Interchangeable Algorithms at Runtime

Intent

Strategy defines a family of interchangeable algorithms, encapsulates each one behind a common interface, and lets the algorithm vary independently of the client that uses it.

That one line hides the whole point: the thing that changes (the algorithm) is pulled out of the thing that stays (the orchestration around it), so you can add, swap, or test algorithms without touching the caller.

The Problem

You start with one way of doing something. Then the business gives you a second way. Then a third. The naive evolution looks like this:

class Checkout {
  pay(method) {
    if (method === "card")        { /* 30 lines of Stripe logic */ }
    else if (method === "upi")    { /* 25 lines of UPI logic */ }
    else if (method === "wallet") { /* 20 lines of wallet logic */ }
    else if (method === "emi")    { /* 40 lines of EMI logic */ }
    // ...and this method keeps growing
  }
}

This is the classic conditional sprawl smell. Every new payment method edits the same method, so:

• The class violates OCP — you reopen Checkout for every new behavior.
• The class violates SRP — it now knows the internals of card, UPI, wallet, and EMI processing.
• Branches share mutable locals and accidentally couple. A change to the wallet branch can break the card branch in code review nobody reads carefully.
• You can’t unit-test “EMI logic” in isolation; you have to drive it through the giant method.
• Two methods (pay, refund) both grow parallel if/else ladders that must stay in sync.

The inheritance “fix” is just as bad: a CardCheckout extends Checkout, UpiCheckout extends Checkout hierarchy locks the algorithm into the object’s type at construction. You cannot change a user’s payment method mid-session without rebuilding the object, and you cannot combine a payment algorithm with an orthogonal axis (say, a fraud-check algorithm) without a combinatorial explosion of subclasses.

The trigger for Strategy is: “I have one job, but several interchangeable ways to do it, and the choice should be data, not a new keyword.”

Structure

Strategy splits the world into three roles. The Context holds a reference to a Strategy interface; concrete strategies implement it; the client picks which concrete strategy the context gets.

            ┌─────────────────────────┐        ┌───────────────────────────┐
            │        Context          │        │   «interface» Strategy    │
            ├─────────────────────────┤        ├───────────────────────────┤
            │ - strategy: Strategy    │◇──────▶ │ + execute(ctx): Result    │
            ├─────────────────────────┤  has-a └────────────▲──────────────┘
            │ + setStrategy(s)        │                     │ implements
            │ + doWork(): Result      │          ┌──────────┼──────────────┐
            │     → strategy.execute()│          │          │              │
            └─────────────────────────┘   ┌──────┴───┐ ┌────┴─────┐ ┌──────┴────┐
                       ▲                   │StrategyA │ │StrategyB │ │StrategyC  │
                       │ uses              ├──────────┤ ├──────────┤ ├───────────┤
                 ┌─────┴──────┐            │+execute()│ │+execute()│ │+execute() │
                 │   Client   │            └──────────┘ └──────────┘ └───────────┘
                 └────────────┘

The diamond (◇) is the load-bearing detail: the Context composes a Strategy (has-a), it does not inherit an algorithm (is-a). That single arrow is why Strategy is the canonical demonstration of composition over inheritance.

Participants

A Real Example: Payment Routing, Not a Toy

The textbook example is “sort an array with different comparators.” Real systems use Strategy for payment routing: given a charge, pick a processor (Stripe, Razorpay, in-house wallet), each with its own fee model, idempotency rules, and failure handling. The Context (PaymentService) owns the invariant parts — validating the request, recording an audit log, normalizing the result — and delegates only the processor-specific call.

A note before the code: real payment fees use integer or decimal arithmetic, never floats, and a single explicit rounding rule. Below, every language computes the Stripe fee the same way — floor(amountMinor * 29 / 1000) plus a flat 30 — using integer math so the three tabs produce bit-identical results. (The earlier float-plus-round() version produced different fees on .5 boundaries because round(), Math.round(), and std::lround() use three different rounding modes. Don’t ship that.)

interface PaymentResult {
ok: boolean;
reference: string;
feeMinor: number; // fee in minor units (paise/cents)
}

interface ChargeRequest {
amountMinor: number;
currency: string;
idempotencyKey: string;
}

// --- Strategy ---
interface PaymentStrategy {
readonly name: string;
charge(req: ChargeRequest): Promise<PaymentResult>;
}

class StripeStrategy implements PaymentStrategy {
readonly name = "stripe";
async charge(req: ChargeRequest): Promise<PaymentResult> {
  // 2.9% + 30, integer math, floor — deterministic across languages
  const fee = Math.floor((req.amountMinor * 29) / 1000) + 30;
  // ... real SDK call keyed by req.idempotencyKey ...
  return { ok: true, reference: `ch_${req.idempotencyKey}`, feeMinor: fee };
}
}

class WalletStrategy implements PaymentStrategy {
readonly name = "wallet";
async charge(req: ChargeRequest): Promise<PaymentResult> {
  // internal ledger debit, no external fee
  return { ok: true, reference: `wl_${req.idempotencyKey}`, feeMinor: 0 };
}
}

// --- Context: owns the invariant workflow ---
class PaymentService {
constructor(private strategy: PaymentStrategy) {}

setStrategy(s: PaymentStrategy): void { this.strategy = s; }

async pay(req: ChargeRequest): Promise<PaymentResult> {
  if (req.amountMinor <= 0) throw new Error("amount must be positive");
  console.log(`[audit] charging via ${this.strategy.name}`);
  const result = await this.strategy.charge(req); // the only variable step
  console.log(`[audit] ref=${result.reference} fee=${result.feeMinor}`);
  return result;
}
}

// --- Client selects strategy from data, guarding the unknown key ---
const registry: Record<string, PaymentStrategy> = {
stripe: new StripeStrategy(),
wallet: new WalletStrategy(),
};

// Safe under noUncheckedIndexedAccess: the lookup can miss.
function getStrategy(key: string): PaymentStrategy {
const s = registry[key];
if (!s) throw new Error(`unknown payment strategy: ${key}`);
return s;
}

const svc = new PaymentService(getStrategy("wallet"));

For amountMinor = 1000, all three tabs return fee = floor(1000*29/1000) + 30 = 29 + 30 = 59 — identical, because integer math removes the rounding-mode ambiguity entirely.

Notice what the Context kept: amount validation, audit logging, result normalization. Those are invariant across every processor. Only charge() varies. If tomorrow you add RazorpayStrategy, you write one class and register it — PaymentService does not change. That is OCP made literal.

Strategies as plain functions

When a strategy has no state and one method, an interface is ceremony. In TS and Python a strategy is often just a function — (req) => Result — stored in a map. This is the function-object form of Strategy and is the idiomatic choice for stateless cases like comparators or compression codecs.

type Compressor = (data: Uint8Array) => Uint8Array;

const codecs: Record<string, Compressor> = {
none: (d) => d,
gzip: (d) => gzipSync(d),   // from a real lib
lz4:  (d) => lz4Compress(d),
};

function getCodec(key: string): Compressor {
const c = codecs[key];               // Compressor | undefined under
if (!c) throw new Error(`unknown codec: ${key}`); // noUncheckedIndexedAccess
return c;
}

class Archive {
constructor(private compress: Compressor) {}
write(data: Uint8Array): Uint8Array {
  return this.compress(data); // strategy is a first-class value
}
}

// pick by config / file size / CPU budget — at runtime, key-checked
const arc = new Archive(getCodec(process.env.CODEC ?? "gzip"));

When to Use It

Reach for Strategy when all of these hold:

• You have multiple interchangeable ways to do one job (route a payment, sort, compress, price, retry-backoff).
• The choice should be made at runtime — from config, user input, A/B flags, or load conditions — not fixed at compile time.
• The algorithms are mutually independent; each can be reasoned about and tested alone.
• You expect the set of algorithms to grow, and you want new ones to be additive.

Concrete production triggers: pricing/discount engines, retry/backoff policies, fraud-scoring models behind a flag, route planners (fastest/shortest/eco), serialization formats, and rate-limiter algorithms (token bucket vs. sliding window).

When NOT to Use It

Strategy is over-applied more often than it’s missing. Two stable branches that will never grow do not need it.

• Only two cases that never change → a boolean flag or a simple if is honest and cheaper. Don’t add an interface, two classes, and a registry to hide one if.
• Strategies aren’t actually interchangeable → if each “strategy” needs a different method signature or different inputs, you don’t have a family of algorithms; you have different operations. Forcing them behind one interface produces leaky instanceof checks.
• The variation is over object lifecycle, not algorithm choice → that’s State, not Strategy (contrasted below).
• Steps differ but the skeleton is identical → if the algorithms share 80% of a sequence and differ only in a few steps, Template Method (inheritance) or a Strategy per varying step fits better than one monolithic strategy (contrasted below).

Strategy vs. State vs. Template Method

These three are constantly confused in interviews because Strategy and State share identical class diagrams, and Strategy and Template Method solve the same “vary one piece of an algorithm” problem with opposite mechanisms. Know the distinctions cold.

Strategy vs. State

Structurally, State is Strategy: a Context delegates to a swappable object behind an interface. The difference is entirely about who swaps it and why:

The tell: if WalletStrategy.charge() ever sets service.setStrategy(somethingElse), you’ve drifted from Strategy into State. In Strategy, a strategy never decides what the next strategy is — that’s the client’s job. In State, transitions live inside the state objects.

Litmus test for an interview: “Does the swappable object change the Context’s swappable object? If yes, it’s State. If the choice comes from outside and stays fixed for the operation, it’s Strategy.”

Strategy vs. Template Method

Both let you vary part of an algorithm while keeping a fixed skeleton. They differ in mechanism, and that drives every trade-off:

Template Method puts the invariant skeleton in a base class with protected hook methods subclasses override. Strategy puts the skeleton in the Context and delegates the whole varying part to a composed object. Rule of thumb: if the variation is a few small steps inside one fixed sequence, Template Method is less plumbing. If the variation is the entire algorithm, or you need to swap it at runtime, use Strategy.

Relationship to SOLID

• Open/Closed (OCP) — the headline win. New algorithm = new class implementing the interface + a registry entry. Existing, tested code is untouched. This is the textbook mechanism by which OCP is achieved.
• Single Responsibility (SRP) — each strategy owns exactly one algorithm; the Context owns orchestration. The giant if/else violated SRP; Strategy restores it.
• Dependency Inversion (DIP) — the Context depends on the Strategy abstraction, not concrete processors. Concrete strategies are injected, so high-level policy doesn’t depend on low-level detail.
• Liskov (LSP) — every concrete strategy must be a true drop-in: same contract, no surprising side effects, no narrowing of inputs. The Stripe-vs-Wallet difference is exactly the divergence to watch: if Stripe charges a fee and rounds one way while Wallet charges nothing and another processor truncates differently, the strategies are no longer freely substitutable. Pin the contract (units, rounding, currency handling) in the interface so any strategy honoring it is a safe drop-in.
• Interface Segregation (ISP) — keep the Strategy interface minimal (one method, ideally). A fat strategy interface forces concrete strategies to implement (or stub) methods they don’t need, which is the smell ISP warns against.

And the design-principle headline: Strategy is the executable form of “favor composition over inheritance” plus “program to an interface, not an implementation.” Those two GoF maxims are the entire pattern. When an interviewer asks why Strategy, the strongest answer ties it back to OCP (additive change) and composition (runtime flexibility without subclass explosion) — not to the UML.