Dynamic dispatch is the runtime mechanism that decides which method implementation to run based on the object's actual type, not the variable's declared type. Most class-based languages implement it with a virtual method table (vtable).
Each class has a table of pointers to its method implementations. Each object holds a hidden pointer to its class's vtable. A virtual call becomes:
Animal a = new Dog();
a.speak();
a ──▶ Dog object ──▶ [Dog vtable]
speak() ──▶ Dog.speak() ← chosen at RUNTIME
The compiler doesn't hard-code Animal.speak; it emits "call slot N of whatever vtable this object points to."
Animal a = new Dog(); // declared Animal, actual Dog
a.speak(); // → Dog.speak(), because dispatch uses the OBJECT
| Language | Default | Notes |
|---|---|---|
| Java | Virtual by default | final/static/private are non-virtual |
| C++ | Non-virtual by default | Must mark virtual for dynamic dispatch |
| Python | Always dynamic | Method lookup via the object's dict/MRO |
There's a small cost (an indirection) and it blocks inlining. In C++, forgetting virtual means calls bind statically and overrides are silently not called — a subtle bug.
Understanding dispatch explains why overriding works and why the declared type doesn't determine behavior — a common source of confusion.
It also clarifies real consequences: the performance cost of virtual calls, why constructors shouldn't call virtual methods, and why C++ requires virtual explicitly.