Liskov substitution

LSP: a subtype must be substitutable for its supertype without surprising any code that holds the supertype. Barbara Liskov’s formulation: if S is a subtype of T, then objects of type T may be replaced with objects of type S without altering any of the desirable properties of the program. The practical reading: every function written against T — using only what T’s contract promises — must keep working when handed an S, with no special knowledge that an S is present.

This is a constraint on the subclass author, paid to a caller they will never meet. The caller coded against Rectangle. The subclass author must make Square behave like a Rectangle in every way that caller could legitimately depend on. If they can’t, Square is not a subtype of Rectangle — whatever the extends keyword says.

The contract has four clauses; violate any one and substitution breaks. Behavioral subtyping spells out exactly what “behave like the supertype” means:

abstract class Account {
  // precondition: amount > 0
  // postcondition: balance decreases by exactly `amount`; never throws for a valid amount
  abstract withdraw(amount: number): void;
}

• Don’t strengthen preconditions. The subtype may not demand more of callers than the parent did. If Account.withdraw accepts any positive amount, a subtype that rejects amounts over 100 breaks callers who reasonably passed 500.
• Don’t weaken postconditions. The subtype must deliver at least what the parent promised. If withdraw guarantees the balance drops by amount, a subtype that sometimes drops it by less has lied to every caller.
• Don’t throw new exceptions the parent’s contract never declared. A caller that handled withdraw’s documented errors will not catch a surprise NotSupportedError.
• Preserve invariants the parent maintains (e.g. “balance is never negative”). The subtype inherits the duty to keep them true.

These are the only knobs. Every LSP violation is one of these four, made concrete.

Rectangle/Square: the subtype strengthens an invariant the parent didn’t have, and it breaks callers. The textbook case. A Rectangle lets width and height vary independently — that independence is part of its contract, even though no method declares it.

class Rectangle {
  constructor(protected w: number, protected h: number) {}
  setWidth(w: number) { this.w = w; }
  setHeight(h: number) { this.h = h; }
  area() { return this.w * this.h; }
}

class Square extends Rectangle {
  // a square must keep w === h, so each setter mutates both
  setWidth(w: number) { this.w = w; this.h = w; }
  setHeight(h: number) { this.w = h; this.h = h; }
}

// a caller written against Rectangle's contract
function grow(r: Rectangle) {
  r.setWidth(5);
  r.setHeight(4);
  return r.area(); // a Rectangle reader expects 20
}

grow(new Rectangle(1, 1)); // 20  ✅
grow(new Square(1, 1));    // 16  ❌  — setHeight clobbered the width

grow did nothing wrong; it used only Rectangle’s public contract. Square strengthened it with a new invariant (w === h) that the parent never promised to keep, and that extra invariant weakened the postcondition of setWidth (it no longer leaves height alone). Geometrically a square is-a rectangle; behaviorally, a mutable Square is not a substitutable Rectangle. The is-a intuition is the trap.

The read-only collection: the subtype throws a new exception, so callers can’t treat it as the supertype. A second canonical shape, and the one you hit more often in real code.

class List<T> {
  protected items: T[] = [];
  add(item: T) { this.items.push(item); }
  get(i: number) { return this.items[i]; }
}

class ReadOnlyList<T> extends List<T> {
  add(_item: T): never {
    throw new Error("ReadOnlyList is immutable"); // a NEW exception the parent never threw
  }
}

function appendAuditEntry(log: List<string>) {
  log.add("user logged in"); // valid against List's contract — but throws for ReadOnlyList
}

ReadOnlyList is type-compatible — it has every method List has. The compiler is happy. But it violates the “no new exceptions” clause: appendAuditEntry, holding a List, calls the contractually-valid add and gets an exception the List contract never warned about. ReadOnlyList is a narrower behaviour wearing a wider type. The fix is to invert the hierarchy: the read-only interface is the supertype, and the mutable list extends it by adding add — you never inherit a capability and then take it away.

The tell: when callers start writing if (x instanceof Sub), a subtype has already broken LSP. A subtype that doesn’t truly substitute forces the caller to discover its real type and branch on it:

function grow(r: Rectangle) {
  if (r instanceof Square) {
    // special-case the thing that was supposed to be substitutable
    r.setWidth(5);
    return r.area();
  }
  r.setWidth(5);
  r.setHeight(4);
  return r.area();
}

The moment that instanceof appears, the abstraction has failed: the caller now knows about the subclass, which is exactly the coupling polymorphism was meant to remove. Every new subtype adds another branch here (an Open/Closed violation too — the function is no longer closed to new types). So instanceof Sub inside code that holds the supertype is not just ugly; it is the compiler-invisible LSP violation made visible. Treat it as a failed-substitution alarm, not a coding-style nit.