Подстановка Лисков

LSP: подтип должен подставляться вместо своего супертипа, не удивляя никакой код, который держит супертип. Формулировка Барбары Лисков: если S — подтип T, то объекты типа T могут быть заменены объектами типа S без изменения каких-либо желаемых свойств программы. Практическое прочтение: каждая функция, написанная против T — использующая только то, что обещает контракт T, — должна продолжать работать, получив S, без всякого специального знания о том, что присутствует S.

Это ограничение на автора подкласса, уплачиваемое вызывающему, которого он никогда не встретит. Вызывающий писал код против Rectangle. Автор подкласса обязан сделать так, чтобы Square вёл себя как Rectangle во всём, на что этот вызывающий мог законно опираться. Если он не может — Square не является подтипом Rectangle, что бы ни говорило ключевое слово extends.

У контракта четыре пункта; наруши любой — и подстановка ломается. Поведенческое подтипирование точно проговаривает, что значит «вести себя как супертип»:

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

• Не усиливай предусловия. Подтип не вправе требовать от вызывающих большего, чем требовал родитель. Если Account.withdraw принимает любую положительную сумму, подтип, отвергающий суммы свыше 100, ломает вызывающих, которые обоснованно передали 500.
• Не ослабляй постусловия. Подтип обязан выдать как минимум то, что обещал родитель. Если withdraw гарантирует, что баланс уменьшится на amount, подтип, который иногда уменьшает его меньше, солгал каждому вызывающему.
• Не бросай новых исключений, которые контракт родителя никогда не объявлял. Вызывающий, обработавший задокументированные ошибки withdraw, не поймает внезапную NotSupportedError.
• Сохраняй инварианты, которые поддерживает родитель (например, «баланс никогда не отрицателен»). Подтип наследует обязанность держать их истинными.

Это единственные рычаги. Каждое нарушение LSP — один из этих четырёх, ставший конкретным.

Rectangle/Square: подтип усиливает инвариант, которого у родителя не было, и это ломает вызывающих. Хрестоматийный случай. Rectangle позволяет ширине и высоте меняться независимо — эта независимость часть его контракта, хотя ни один метод её не объявляет.

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 не сделал ничего плохого; он использовал только публичный контракт Rectangle. Square усилил его новым инвариантом (w === h), который родитель никогда не обещал держать, и этот лишний инвариант ослабил постусловие setWidth (он больше не оставляет высоту в покое). Геометрически квадрат является прямоугольником; поведенчески мутабельный Square не является подставляемым Rectangle. Интуиция is-a — это ловушка.

Read-only-коллекция: подтип бросает новое исключение, поэтому вызывающие не могут обращаться с ним как с супертипом. Вторая каноническая форма, и та, что чаще встречается в реальном коде.

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 совместим по типу — у него есть каждый метод, что есть у List. Компилятор доволен. Но он нарушает пункт «никаких новых исключений»: appendAuditEntry, держа List, вызывает контрактно-валидный add и получает исключение, о котором контракт List никогда не предупреждал. ReadOnlyList — это более узкое поведение, носящее более широкий тип. Исправление — перевернуть иерархию: read-only-интерфейс становится супертипом, а мутабельный список расширяет его, добавляя add — ты никогда не наследуешь возможность, чтобы затем её отнять.

Признак: когда вызывающие начинают писать if (x instanceof Sub), подтип уже сломал LSP. Подтип, который по-настоящему не подставляется, вынуждает вызывающего узнать его реальный тип и ветвиться по нему:

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();
}

В тот момент, когда появляется этот instanceof, абстракция провалилась: вызывающий теперь знает о подклассе, а это ровно та связанность, которую полиморфизм был призван убрать. Каждый новый подтип добавляет сюда ещё одну ветку (заодно и нарушение Open/Closed — функция больше не закрыта для новых типов). Так что instanceof Sub внутри кода, который держит супертип, — не просто уродство; это невидимое компилятору нарушение LSP, ставшее видимым. Воспринимай его как сигнал тревоги о провале подстановки, а не как мелкую придирку к стилю.