Design Patterns That Actually Come Up

The shortlist

How to pick — follow the force, not the name

Patterns are answers to recurring forces. Start from the problem you can feel in the code, and the pattern falls out:

In an interview, say the force out loud first ("seat-assignment policy varies → I'll put it behind a Strategy"), then name the pattern. Naming without the force is buzzword bingo; the force without the name still earns full credit.

Strategy — the most useful one

Encapsulate interchangeable algorithms behind a common interface and inject the one you want. Kills if/else-on-type and satisfies Open/Closed.

interface PricingStrategy { price(base: number): number; }

const regular: PricingStrategy = { price: (b) => b };
const member:  PricingStrategy = { price: (b) => b * 0.9 };

class Checkout {
  constructor(private strategy: PricingStrategy) {}
  total(base: number) { return this.strategy.price(base); }
}
// Add a BlackFridayStrategy later without touching Checkout.

Observer — events & notifications

type Listener<T> = (event: T) => void;

class Subject<T> {
  private listeners = new Set<Listener<T>>();
  subscribe(l: Listener<T>) { this.listeners.add(l); return () => this.listeners.delete(l); }
  emit(event: T) { for (const l of this.listeners) l(event); }
}
// priceFeed.subscribe(updateChart); priceFeed.subscribe(checkAlerts);

Watch the fan-out. The subject keeps a subscriber list and, on every publish, calls the same update on each one — it never knows their concrete types or how many there are. Subscribe, publish, then unsubscribe one and publish again.

State — behavior that changes with the object's mode

When an object behaves differently depending on a status field, that logic tends to sprawl into the same switch (status) copied across every method. The State pattern gives each mode its own object that knows which events it accepts and which state comes next — so an illegal move (pressing pause while already Stopped) is simply refused, not a forgotten if.

Step through a media player below. Watch how each event is handled by the current state, and add an illegal event to the list — it gets ignored because that state has no transition for it.

interface PlayerState { play(p: Player): void; stop(p: Player): void; }

class Stopped implements PlayerState {
  play(p: Player) { p.state = new Playing(); }   // valid move
  stop(_: Player) {}                             // already stopped — no-op
}
class Playing implements PlayerState {
  play(_: Player) {}                             // already playing
  stop(p: Player) { p.state = new Stopped(); }
}
class Player {
  state: PlayerState = new Stopped();
  play() { this.state.play(this); }              // no switch — just delegate
  stop() { this.state.stop(this); }
}

The Player has zero if (status === …) branches: each state encapsulates its own transitions. Adding a Paused state is one new class, not an edit to five methods — that's Open/Closed in action.

Singleton — handle with care

It guarantees one instance, but it's global mutable state in disguise: it hides dependencies, complicates tests, and is a footgun under concurrency (use lazy-init with proper locking or eager init). Often dependency injection of a single shared instance is the better answer.

Practice — model state & transitions

These are design problems, not algorithm puzzles. Each one is really "name the states and the events between them" — exactly the State pattern. Write the transition table first, then the code falls out.