Open for extension, closed for modification

OCP: software entities should be open for extension but closed for modification. “Closed for modification” means you can ship new behaviour without editing existing, tested source. “Open for extension” means the design has a seam where new behaviour plugs in. The two together describe code that grows by addition. The canonical anti-pattern is a conditional that switches on a type tag:

type Shape =
  | { kind: "circle"; r: number }
  | { kind: "square"; side: number };

function area(s: Shape): number {
  switch (s.kind) {
    case "circle": return Math.PI * s.r ** 2;
    case "square": return s.side ** 2;
  }
}

Add a triangle and you must edit area. Add perimeter and you write a second switch on the same tags. This code is closed for extension (you can’t add a shape without it) and open for modification (you must edit it constantly) — exactly backwards.

The fix is to put the variation behind an interface and let each variant own its code. Invert the dependency: instead of one function knowing every shape, each shape knows how to compute its own area. The switch evaporates into the type system.

interface Shape {
  area(): number;
}

// circle.ts — a whole new file
class Circle implements Shape {
  constructor(private r: number) {}
  area(): number { return Math.PI * this.r ** 2; }
}

// square.ts — another file
class Square implements Shape {
  constructor(private side: number) {}
  area(): number { return this.side ** 2; }
}

function totalArea(shapes: Shape[]): number {
  return shapes.reduce((sum, s) => sum + s.area(), 0);
}

Now adding a triangle is a new file, triangle.ts, implementing Shape. totalArea is never opened. Nothing that already worked is touched, so nothing that already worked needs re-testing. That is the whole payoff: the blast radius of “new shape” shrinks from “every consumer” to “one new file.”

OCP is a target along ONE axis, not an absolute — you choose which change to make cheap. The shape design above is closed against adding a shape and open against adding an operation: a new operation (perimeter, bounding-box) means editing the Shape interface and every implementing class — the exact pain the switch had, just rotated 90°. This is the expression problem: you can make new-variant cheap or new-operation cheap, rarely both for free.

So OCP is never “closed, full stop.” It is “closed against the axis I predict will vary.” If shapes get added often and operations rarely, the polymorphic design wins. If you mostly add operations to a fixed set of shapes, the switch (or a visitor) is the better bet. Picking the axis is the design decision; the pattern is just bookkeeping once you’ve picked.

Guess the axis wrong and OCP becomes over-engineering — its failure mode is speculative abstraction. An interface, a factory, a registry, a plugin loader: each is real code to read, and each is a bet that a particular variation will arrive. Build a PaymentProviderPlugin framework with dynamic discovery for a product that has had exactly one payment provider for two years and the abstraction earns nothing — you pay the indirection cost on every read and never collect the flexibility.

// Speculative: a plugin system for a variation that hasn't shown up.
interface DiscountStrategy { apply(price: number): number; }
class DiscountRegistry { /* register, resolve, fallback, config... */ }
// ...500 lines of framework, and the app ships exactly one discount: 10% off.

This is YAGNI’s domain. The disciplined default is to write the concrete code (price * 0.9) and refactor to OCP the moment the second real variant appears — when the axis of change is observed, not imagined. Two data points beat one guess.