Polymorphism

Runtime polymorphism: overriding and dynamic dispatch

The kind that matters most in object-oriented design is runtime (or subtype) polymorphism. You define a shared base — an interface or abstract class — that declares a method like area(). Then each subtype overrides it with its own implementation. When you call shape.area(), the language looks at the object's actual type at runtime and picks the matching method. That lookup is called dynamic dispatch.

The crucial part: the variable's declared type can be the general one (Shape), but the behavior that runs is the specific one (Circle.area, Square.area). One call site, many possible behaviors, resolved while the program runs.

interface Shape {
  area(): number; // the shared promise — every shape can do this
}

class Circle implements Shape {
  constructor(private r: number) {}
  area() { return Math.PI * this.r ** 2; } // its own formula
}

class Square implements Shape {
  constructor(private s: number) {}
  area() { return this.s ** 2; } // a different formula
}

const shapes: Shape[] = [new Circle(5), new Square(4)];
for (const s of shapes) {
  console.log(s.area()); // SAME call — dynamic dispatch picks the right one
}

The killer benefit: delete the type switch

The whole payoff is replacing a sprawling if/switch-on-type with a single polymorphic call. Look at the before: the caller has to know every shape and its formula, and you must edit it every time a new shape appears.

// BEFORE — the caller switches on a type tag (fragile)
function area(shape: any): number {
  switch (shape.kind) {
    case "circle":    return Math.PI * shape.r ** 2;
    case "square":    return shape.s ** 2;
    case "triangle":  return 0.5 * shape.b * shape.h;
    // add a new shape? you MUST come back and edit this switch.
    default: throw new Error("unknown shape");
  }
}

// AFTER — one polymorphic call; the caller knows nothing about types
function totalArea(shapes: Shape[]): number {
  return shapes.reduce((sum, s) => sum + s.area(), 0); // that's it
}

The after version never names a concrete shape. Add a Hexagon that implements Shape, and totalArea keeps working untouched. That's the open/closed principle in one breath: your code is open to new shapes, closed to modification.

The wider landscape (so you know the words)

• Runtime / subtype polymorphism — overriding + dynamic dispatch, the one above. This is what people usually mean in OOP design.
• Compile-time polymorphism (overloading) — several methods share a name but differ by their parameters, e.g. add(int, int) vs add(double, double). The compiler picks which one based on the arguments; nothing is decided at runtime.
• Parametric polymorphism (generics / templates) — one piece of code works for many types without caring which, e.g. List<T> or Box<T>. The same logic, parameterized by type.

Reach for polymorphism when…

• You catch yourself writing a switch or if-chain on a type tag (if (kind === "circle")). That's the textbook smell — each branch wants to become an overridden method.
• You have a family of things that do the same job differently — shapes with area(), payment methods with charge(), exporters with write().
• You expect new variants over time and don't want every addition to ripple through caller code.