Strategy

The three participants

A textbook Strategy has three moving parts, and each is small:

• The Strategy interface — one contract every algorithm signs, e.g. RouteStrategy with a single method buildRoute(from, to). This is [[program-to-interfaces]] in its purest form: the client depends on this contract and nothing else.
• Concrete strategies — one small class per algorithm: DriveStrategy, BikeStrategy, WalkStrategy. Each hides its own details (highway graphs, bike-lane maps, footpaths) behind the same method signature. They're interchangeable precisely because they're indistinguishable through the interface.
• The Context — the class that needs the work done (the MapApp). It holds one strategy reference, receives it via the constructor or a setter (that's constructor/setter injection — see [[dependency-injection-and-ioc]]), and delegates: route(A, B) just calls this.strategy.buildRoute(A, B). The context never implements an algorithm and never inspects which one it holds.

The smell it cures: the algorithm-choosing conditional

Strategy exists to kill one specific smell: a growing `if/else` or `switch` that picks an algorithm inline. One method that branches on a mode string, with each branch containing a whole algorithm, has three compounding problems: every new variant means editing a class that already worked (a direct [[open-closed]] violation), the variants can't be tested in isolation because they share locals and state, and the conditional inevitably gets copy-pasted to other places that need the same choice. Strategy replaces the branch point with polymorphism — the 'decision' happens once, when someone plugs a strategy in; after that, calling the method is the dispatch.

interface RouteStrategy {                    // the one shared contract
  buildRoute(from: string, to: string): string;
}

class DriveStrategy implements RouteStrategy {
  buildRoute(a: string, b: string) { return `${a}→highways→${b}`; }
}
class WalkStrategy implements RouteStrategy {
  buildRoute(a: string, b: string) { return `${a}→park path→${b}`; }
}

class MapApp {                                // the context
  constructor(private strategy: RouteStrategy) {}   // injected in
  setStrategy(s: RouteStrategy) { this.strategy = s; }  // swap at runtime
  route(a: string, b: string) {
    return this.strategy.buildRoute(a, b);    // delegate — no if/else
  }
}

const map = new MapApp(new DriveStrategy());
map.route("A", "B");                 // drive route
map.setStrategy(new WalkStrategy()); // user taps 🚶
map.route("A", "B");                 // SAME call, different algorithm

Strategy vs State: same shape, different driver

Strategy's structure — context delegating to a swappable object behind an interface — is identical to the [[state]] pattern, and interviewers love asking the difference. It's about who does the swapping and why. In Strategy, the client picks the algorithm (you tap 🚴 in the maps app), the strategies don't know each other exist, and the chosen strategy rarely changes mid-task. In State, the objects represent modes of being (an order that's Placed, Paid, Shipped), they typically know about each other and trigger their own transitions — paying an order moves it to Paid without any client choosing. One sentence: Strategy is chosen from outside; State switches itself from inside.

Where you'll meet it in the wild

• Sort comparators — Array.sort(cmp), Java's Comparator, C++'s std::sort predicate: the classic function-as-strategy.
• Payment methods — checkout calls pay(amount) on a PaymentStrategy; card, UPI, wallet and PayPal each implement it their own way.
• Compression codecs — an archiver holds a CompressionStrategy (zip, gzip, zstd) and calls compress(bytes) without caring which.
• Pricing & discount rules — seasonal, coupon, loyalty-tier discounts as interchangeable DiscountStrategy objects the cart applies.
• Auth providers — login flows swap AuthStrategy implementations (password, OAuth, magic link); libraries like Passport.js literally call them strategies.
• Route planning — the running example: navigation apps swap routing algorithms per travel mode over the same buildRoute call.

Reach for Strategy when…

• You have many variants of one algorithm — several ways to route, price, compress, sort or authenticate, all doing 'the same job' differently. That's the family Strategy is built for.
• The choice happens at runtime — the user taps a travel-mode chip, a config flag picks a codec, an A/B test assigns a pricing rule. Swapping an object is trivial; rewriting a conditional at runtime is impossible.
• You want each algorithm isolated and testable — every strategy is a small class you can unit-test alone, hand a fake to, or tune without touching its siblings or the context.
• A conditional that picks algorithms keeps growing — an if/else chain over modes that every new feature edits is the flashing sign; Strategy replaces the branches with one polymorphic call and makes new variants pure additions ([[open-closed]]).

Skip it when…

• There's one algorithm and it never varies — an interface, three files and an injection point to wrap a single stable computation is pure ceremony. Inline it and move on; extract a strategy the day a second variant actually appears.
• The variants are trivially small — if each 'algorithm' is one expression (a comparator, a formatter), pass a function argument instead of building the class version. Same pattern, a tenth of the code.