Полиморфизм вместо условий

Запах — это один и тот же повторяющийся switch, а не switch сам по себе. Одиночный switch — это нормально. Проблема в том, что один и тот же набор случаев — та же лестница if (type === ...) — снова появляется в расчёте комиссии, рендеринге чека, обработке возврата и отчётности. Теперь знание «какие виды оплаты существуют и как каждый ведёт себя» размазано по N файлам.

function fee(p: Payment): number {
  switch (p.method) {
    case "card":   return p.amount * 0.029 + 30;
    case "paypal": return p.amount * 0.034 + 49;
    case "wire":   return 0;
  }
}
function label(p: Payment): string {
  switch (p.method) {            // <-- same axis of variation, second site
    case "card":   return "Card";
    case "paypal": return "PayPal";
    case "wire":   return "Wire transfer";
  }
}

Добавить crypto значит править оба — и каждое другое место, где переключаются по p.method. Стоимость нового варианта растёт пропорционально числу мест, которые переключаются по типу.

Замена условия полиморфизмом: перенеси поведение каждого случая на тип. Дай каждому варианту объект, который знает собственные fee, label, refund. Тогда диспетчеризация происходит один раз, силами языка, когда ты вызываешь payment.fee() — switch по методу исчезает из каждого места вызова.

interface PaymentMethod {
  fee(amount: number): number;
  label(): string;
}

class Card implements PaymentMethod {
  fee(amount: number) { return amount * 0.029 + 30; }
  label() { return "Card"; }
}
class Wire implements PaymentMethod {
  fee(_amount: number) { return 0; }
  label() { return "Wire transfer"; }
}

Теперь вызывающие fee и label просто пишут method.fee(amount) и method.label(). Добавить crypto — это один новый класс, единственная добавляющая правка, — а существующие места вызова не меняются. Это конкретное воплощение принципа открытости/закрытости: открыт для расширения (новый класс), закрыт для модификации (ни один существующий switch не тронут).

Таблица диспетчеризации — более лёгкая форма: тот же выигрыш, меньше церемоний. Класс на каждый вариант нужен не всегда. Когда поведение случая мало́ и похоже на данные, поиск по ключу-типу схлопывает те же N switch’ей в одну таблицу. В TypeScript это часто и есть нужная мера структуры.

const METHODS: Record<Payment["method"], {
  fee: (amount: number) => number;
  label: string;
}> = {
  card:   { fee: a => a * 0.029 + 30, label: "Card" },
  paypal: { fee: a => a * 0.034 + 49, label: "PayPal" },
  wire:   { fee: () => 0,             label: "Wire transfer" },
};

const feeOf   = (p: Payment) => METHODS[p.method].fee(p.amount);
const labelOf = (p: Payment) => METHODS[p.method].label;

Добавить crypto — это одна новая запись. А поскольку тип ключа — Payment["method"], TypeScript вынуждает таблицу быть исчерпывающей: пропусти метод — и оно не скомпилируется. Эта проверка компилятором — преимущество таблицы диспетчеризации над написанным руками switch без default.

Senior-компромисс: полиморфизм убирает повторяющиеся условия, но добавляет косвенность и разбрасывает логику одного метода по файлам. Решение — не «полиморфизм хорошо, switch плохо». Это баланс затрат и выгод, который можно почти что записать:

склоняйся к полиморфизму, когда (число мест, переключающихся по этому типу) × (темп прибытия новых вариантов) велико.

• Много мест, много вариантов → полиморфизируй. Новый вариант — это одна добавляющая единица; switch’и исчезают.
• Одно место, стабильный набор → оставь switch. Иерархия классов здесь не покупает ничего: ты обменял пятистрочный локальный switch на файл, который надо открыть, чтобы понять одно поведение. Чтобы увидеть, как fee работает по методам, теперь читаешь три файла вместо одного блока.

Режим отказа — это второй случай, сделанный неправильно: иерархия ради двухвариантного, стабильного различия. if (isAdmin) … else … не нуждается в полиморфном дереве AdminUser/RegularUser. Это избыточная абстракция — косвенность без давления расширения, которое бы её оправдало. Дорогая в откате ошибка — это обычно слишком много структуры ради различия, которое и не собиралось расти.