switch по типу и отвергнутое наследство

switch по типу становится запахом только когда повторяется; сигнал — это число дублирующихся switch, а не сам switch. Один switch по тегу, в одном месте, — это просто функция. Запах — это тот же switch — те же случаи, тот же дискриминант — появляющийся в трёх, четырёх, пяти местах. Теперь каждый новый вариант — это не одна правка, а N правок, и компилятор даже не предупредит тебя о тех, что ты забыл, если ветка default молча ничего не делает.

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

function area(s: Shape): number {
  switch (s.kind) { case "circle": return Math.PI * s.r ** 2; /* ... */ }
}
function perimeter(s: Shape): number {
  switch (s.kind) { case "circle": return 2 * Math.PI * s.r; /* ... */ }
}
function describe(s: Shape): string {
  switch (s.kind) { case "circle": return `circle r=${s.r}`; /* ... */ }
}

Добавь triangle — и ты трогаешь area, perimeter, describe и каждую другую функцию с этим switch. Знание «какие виды существуют» продублировано по всем ним.

Повторяющийся switch по типу — это нарушение открытости/закрытости: добавление варианта вынуждает править существующий, работающий код. OCP говорит, что модуль должен быть открыт для расширения, но закрыт для модификации — ты должен мочь добавить triangle, не открывая заново area. Разбросанный switch делает это невозможным: новый случай приходится вклинивать в каждую функцию, которая диспетчеризует по kind. Замена условной логики полиморфизмом переворачивает это. Перенеси каждую ветку случая на тип, чтобы случаи одного switch стали методами одного объекта, а диспетчеризация — виртуальным вызовом языка.

interface Shape {
  area(): number;
  perimeter(): number;
  describe(): string;
}
class Circle implements Shape {
  constructor(private r: number) {}
  area() { return Math.PI * this.r ** 2; }
  perimeter() { return 2 * Math.PI * this.r; }
  describe() { return `circle r=${this.r}`; }
}

Добавить Triangle теперь — один новый класс, реализующий интерфейс — компилятор вынуждает тебя предоставить каждый метод, и ни один существующий класс не открывается заново. N switch свернулись в N методов в одном месте на тип.

Отвергнутое наследство: подкласс наследует методы, которые ему не нужны, и глушит их, бросает на них исключения или выхолащивает — доказательство того, что отношение «является» ложно. Наследование — это обещание: Penguin является Bird, поэтому везде, где код ожидает Bird, работает Penguin. Когда подклассу приходится переопределять унаследованный метод, чтобы он ничего не делал, бросал NotSupported или возвращал бессмысленное значение, он отвергает наследство — говорит тебе, что на самом деле он не та вещь.

class Bird {
  fly(): void { /* move through the air */ }
  layEgg(): Egg { /* ... */ }
}
class Penguin extends Bird {
  fly(): void {
    throw new Error("penguins can't fly"); // refused bequest
  }
}

Penguin унаследовал fly() лишь затем, чтобы от него отречься. Каждый вызывающий, который держит Bird и вызывает fly(), теперь — латентный краш для пингвинов, назревающее нарушение Лисков. Переопределение-через-исключение — это запах; ложный extends — это болезнь.

Лечи отвергнутое наследство заменой наследования делегированием: сохрани то, что действительно переиспользуешь, отбрось ложное «является». Если классу нужно какое-то поведение родителя, но не его тип, держи будущего родителя как поле и делегируй ему, выставляя только те методы, которые действительно применимы. Класс перестаёт быть Bird и начинает иметь нужное ему поведение откладывания яиц — композиция заменяет ложь фактом.

class Penguin {
  private layer = new EggLaying(); // reuse without inheriting
  layEgg(): Egg { return this.layer.layEgg(); }
  swim(): void { /* what penguins actually do */ }
  // no fly() exists to refuse — the interface is honest
}

Теперь ни один вызывающий не может попросить Penguin fly(), потому что Penguin никогда не заявлял, что он Bird. Наследство не отвергнуто; оно никогда не было принято. Тянись к интерфейсу (EggLayer), если несколько типов разделяют контракт, и делегируй реализацию.