Runtime Polymorphism, Virtual Methods and Dynamic Dispatch

How the call is resolved

When a method can be overridden, the compiler cannot know at compile time which implementation will run — the variable's declared type says Notification, but the object might be an SmsNotification. So the decision is deferred to runtime: each class has a table of method pointers (a vtable), each object knows its class, and the call is one extra indirection through that table.

• Java: every non-final, non-private, non-static method is virtual by default.
• C++: only methods marked virtual are dispatched dynamically; the rest are resolved at compile time.
• Python and JavaScript: methods are looked up on the object at call time, so everything is effectively virtual.

Abstract class or interface?

The practical rule: reach for an interface first, because a class can implement several and it keeps the inheritance slot free. Move to an abstract class only when there is genuine shared state to hold.

Replacing conditional chains

The most valuable everyday use of polymorphism is deleting switch statements that grow every time a case is added.

double area(Shape s) {
    if (s.type == CIRCLE)    return Math.PI * s.r * s.r;
    if (s.type == SQUARE)    return s.side * s.side;
    if (s.type == RECTANGLE) return s.w * s.h;
    throw new IllegalArgumentException("unknown shape");
}

interface Shape { double area(); }

record Circle(double r)              implements Shape { public double area() { return Math.PI * r * r; } }
record Square(double side)           implements Shape { public double area() { return side * side; } }
record Rectangle(double w, double h) implements Shape { public double area() { return w * h; } }

This is the open/closed principle in one diff: the system is open to new shapes and closed to modification of existing code. The unreachable "unknown shape" branch disappears too, because the type system now guarantees it.