Polymorphism over conditionals

The smell is the same switch repeated, not a switch by itself. A lone switch is fine. The problem is when the same set of cases — the same if (type === ...) ladder — reappears in fee calculation, receipt rendering, refund handling, and reporting. Now the knowledge “what kinds of payment exist and how each behaves” is smeared across N files.

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";
  }
}

Adding crypto means editing both — and every other site that switches on p.method. The cost of a new variant scales with the number of sites that switch on the type.

Replace conditional with polymorphism: move each case’s behaviour onto the type. Give each variant an object that knows its own fee, label, refund. Dispatch then happens once, by the language, when you call payment.fee() — the per-method switch disappears from every call site.

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"; }
}

Now fee and label callers just write method.fee(amount) and method.label(). Adding crypto is one new class — a single, additive edit — and existing call sites don’t change. This is the Open/Closed Principle made concrete: open for extension (new class), closed for modification (no existing switch touched).

A dispatch map is the lighter-weight form — same win, less ceremony. You don’t always need a class per variant. When the per-case behaviour is small and data-like, a lookup keyed by the type collapses the same N switches into one table. This is often the right amount of structure in 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;

Adding crypto is one new entry. And because the key type is Payment["method"], TypeScript forces the table to be exhaustive — leave out a method and it won’t compile. That compiler check is the dispatch-map’s edge over a hand-written switch with no default.

Senior tradeoff: polymorphism removes repeated conditionals but adds indirection and scatters one method’s logic across files. The decision isn’t “polymorphism good, switch bad.” It’s a cost-benefit you can almost write down:

lean to polymorphism when (number of sites that switch on this type) × (rate at which new variants arrive) is high.

• Many sites, many variants → polymorphise. A new variant is one additive unit; the switches vanish.
• One site, stable set → keep the switch. A class hierarchy here buys nothing: you’ve traded a five-line local switch for a file you must open to understand one behaviour. To see how fee works across methods you now read three files instead of one block.

The failure mode is the second case done wrong: a hierarchy for a two-case, stable distinction. if (isAdmin) … else … does not need an AdminUser/RegularUser polymorphic tree. That’s over-abstraction — indirection with no extension pressure to justify it. The expensive-to-undo mistake is usually too much structure for a distinction that was never going to grow.