This lesson builds on Composition over inheritance. Strategy is that principle applied to one algorithm.

Strategy puts each version of an algorithm in its own class behind one shared interface. The object that needs the result holds one of those classes and calls it through the interface. It does not know which version it holds.

Strategy does not remove the decision about which version to run. It moves that decision out of the code that does the work. Someone still has to choose.

Start from a growing if-chain

A ride app quotes fares. The first release has one rule: a base fee plus a price per kilometer. Then the business adds surge pricing for busy hours. Then shared rides at a discount. Then a flat airport rate. Each rule lands in the same method.

type Trip = { km: number };

class FareCalculator {
  calculate(trip: Trip, mode: string): number {
    const standard = 2.5 + 1.2 * trip.km;
    if (mode === "standard") return standard;
    if (mode === "surge") return standard * this.surgeMultiplier();
    if (mode === "shared") return Math.max(4, standard * 0.7);
    if (mode === "airport") return this.airportFlatRate(trip);
    throw new Error("Unknown pricing mode: " + mode);
  }
  private surgeMultiplier(): number { return 1.8; }
  private airportFlatRate(_trip: Trip): number { return 25; }
}

This works for two rules. It decays as rules arrive:

• every new rule edits a method that already works, so every rule is at risk
• two engineers adding two rules edit the same lines and fight merge conflicts
• the class collects helpers and data that only one rule needs
• a test for the airport rate still runs through code built for surge pricing

Move each rule into its own class

Strategy says: extract each branch into its own class, and make all of them implement one interface. The original class, now called the context, keeps a reference to one strategy and delegates to it. The context no longer knows any formula.

interface PricingStrategy {
  price(trip: Trip): number;
}

class StandardPricing implements PricingStrategy {
  price(trip: Trip) {
    return 2.5 + 1.2 * trip.km;
  }
}

class SurgePricing implements PricingStrategy {
  constructor(private multiplier: number) {}
  price(trip: Trip) {
    return new StandardPricing().price(trip) * this.multiplier;
  }
}

class SharedPricing implements PricingStrategy {
  price(trip: Trip) {
    return Math.max(4, new StandardPricing().price(trip) * 0.7);
  }
}

class FareQuote {
  constructor(private pricing: PricingStrategy) {}

  setStrategy(pricing: PricingStrategy) {
    this.pricing = pricing;
  }

  total(trip: Trip): number {
    return this.pricing.price(trip); // no if-chain, no formula
  }
}

The client, here a checkout screen, picks the strategy. It can change the strategy at runtime with setStrategy, for example when surge hours begin.

Map the roles

Role	In this example	Job
Context	FareQuote	Holds a strategy reference and calls it through the interface
Strategy	PricingStrategy	Declares the one method every variant implements
Concrete strategies	StandardPricing, SurgePricing, SharedPricing	Each implements one version of the algorithm
Client	Checkout screen	Chooses a strategy and passes it to the context

Reach for it when the variants keep coming

• an object needs different versions of one algorithm and must switch between them at runtime
• several classes are identical except for how they perform one behavior
• an algorithm brings data and dependencies that the business class should not carry
• a large conditional picks between versions of the same algorithm

Skip it when the algorithm almost never changes. Two branches that have been stable for a year do not need an interface and three classes.

Implement it in five steps

1. Find the algorithm that changes often, or the conditional that picks between its versions.
2. Declare a strategy interface with one method that every version can implement.
3. Move each version into its own class that implements the interface.
4. Give the context a field of the interface type and a setter. The context talks to the strategy only through the interface.
5. Make the client choose a strategy and pass it to the context.

Name what it costs

You gain	You pay
Swap algorithms at runtime	More classes and an interface, even for a choice that rarely changes
Algorithm code and data live apart from the code that uses them	The client must understand the differences between strategies to pick one
Composition replaces a subclass per variant	In languages with lambdas, a class per strategy can be ceremony
Add a strategy without editing the context (open/closed)	Every strategy must fit one method signature, even when a variant needs more input

Do not confuse it with its neighbors

Pattern	Looks like Strategy because	Differs because
State	A context delegates to a swappable helper	State represents lifecycle-dependent behavior and transitions, which states or the context can trigger. Strategies usually remain independent algorithm choices.
Template Method	It varies part of an algorithm	Its step implementations belong to a subclass. Clients can choose a subclass instance at runtime. Strategy instead replaces a collaborator on the context object.
Command	It wraps behavior in an object	Command turns any operation into an object you can queue, log, or undo. Strategy describes different ways to do the same job.
Bridge	The class diagram is nearly identical	Bridge splits a whole class into two hierarchies that grow independently. Strategy swaps one algorithm.
Decorator	It changes behavior without subclassing the object	Decorator changes an object's skin by wrapping it. Strategy changes its guts by replacing an internal piece.

Retrieve and apply

Answer without scrolling up. Then say the reason out loud, as you would in an interview.

Continue to Template Method to see the inheritance-based way to vary only some steps of an algorithm.