Method Overriding and Runtime Polymorphism

Master runtime polymorphism through method overriding — virtual functions, dynamic dispatch, vtables, and how the compiler resolves method calls at runtime.

Introduction

Method overriding is the mechanism that makes runtime polymorphism possible. While overriding simply means redefining a parent class method in a child class, the real power lies in what happens during execution — the program decides which version of the method to call based on the actual object type, not the reference type. This is called dynamic dispatch, and it is the foundation of flexible, extensible object-oriented design.

In this guide, we focus on method overriding as the enabler of runtime polymorphism, exploring how languages implement dynamic dispatch, what virtual functions are, how vtables work internally, and how to design systems that leverage polymorphic behavior effectively.

Understanding Runtime vs Compile-Time Polymorphism

Polymorphism means "many forms." In OOP, it manifests in two ways:

Aspect	Compile-Time (Static)	Runtime (Dynamic)
Mechanism	Method overloading	Method overriding
Binding	Early binding (at compile time)	Late binding (at runtime)
Decision based on	Method signature (parameters)	Actual object type
Performance	Faster (resolved at compile time)	Slight overhead (vtable lookup)
Flexibility	Limited	Highly extensible
Keyword	Same method name, different params	`virtual`/`override`/`@Override`

Runtime polymorphism through method overriding allows you to write code that works with base class references but automatically calls the correct derived class implementation.

How Dynamic Dispatch Works

When you call an overridden method through a base class reference, the runtime system determines which implementation to execute:

java example

// The magic of runtime polymorphism
Animal animal = new Dog();  // Reference type: Animal, Object type: Dog
animal.speak();             // Calls Dog's speak(), NOT Animal's speak()

// The compiler doesn't know which speak() to call at compile time
// The JVM resolves this at RUNTIME based on the actual object

The Virtual Method Table (vtable)

Most languages implement dynamic dispatch using a vtable — a lookup table of method pointers that each object carries:

fields (name, age, etc.)		speak() → Dog.speak
		eat() → Animal.eat
fields (name, age, etc.)		speak() → Cat.speak
		eat() → Animal.eat

When animal.speak() is called, the runtime:

Follows the object's vtable pointer
Looks up the speak() entry in the vtable
Calls the function at that address

This is why it's called "late binding" — the actual method address isn't known until the program runs.

Implementing Runtime Polymorphism

Java Implementation

Example

// Base class with methods meant to be overridden abstract class Shape { protected String color; public Shape(String color) { this.color = color; } // Method to be overridden - polymorphic behavior public abstract double area(); public abstract double perimeter(); // Template method using polymorphic calls public void printInfo() { System.out.println(getClass().getSimpleName() + " [" + color + "]"); System.out.println(" Area: " + area()); // Calls derived version! System.out.println(" Perimeter: " + perimeter()); // Calls derived version! } } class Circle extends Shape { private double radius; public Circle(String color, double radius) { super(color); this.radius = radius; } @Override public double area() { return Math.PI * radius * radius; } @Override public double perimeter() { return 2 * Math.PI * radius; } } class Rectangle extends Shape { private double width, height; public Rectangle(String color, double width, double height) { super(color); this.width = width; this.height = height; } @Override public double area() { return width * height; } @Override public double perimeter() { return 2 * (width + height); } } // Runtime polymorphism in action public class PolymorphismDemo { public static void main(String[] args) { // Array of base class references holding different objects Shape[] shapes = { new Circle("Red", 5.0), new Rectangle("Blue", 4.0, 6.0), new Circle("Green", 3.0) }; // Same method call, different behavior based on actual type for (Shape shape : shapes) { shape.printInfo(); // Dynamic dispatch decides which area()/perimeter() runs } } }

C++ Implementation with Virtual Functions

In C++, you must explicitly declare methods as virtual to enable dynamic dispatch:

Example

#include <iostream> #include <vector> #include <memory> class Shape { protected: std::string color; public: Shape(const std::string& c) : color(c) {} // VIRTUAL keyword enables dynamic dispatch virtual double area() const = 0; // Pure virtual (abstract) virtual double perimeter() const = 0; // Pure virtual (abstract) // Virtual destructor is ESSENTIAL for polymorphic classes virtual ~Shape() = default; void printInfo() const { std::cout << "Shape [" << color << "]" << std::endl; std::cout << " Area: " << area() << std::endl; // Virtual call std::cout << " Perimeter: " << perimeter() << std::endl; } }; class Circle : public Shape { double radius; public: Circle(const std::string& c, double r) : Shape(c), radius(r) {} // override keyword catches errors if base method doesn't exist double area() const override { return 3.14159 * radius * radius; } double perimeter() const override { return 2 * 3.14159 * radius; } }; class Triangle : public Shape { double a, b, c; public: Triangle(const std::string& col, double a, double b, double c) : Shape(col), a(a), b(b), c(c) {} double area() const override { double s = (a + b + c) / 2; return std::sqrt(s * (s-a) * (s-b) * (s-c)); } double perimeter() const override { return a + b + c; } }; int main() { // Polymorphic container using base class pointers std::vector<std::unique_ptr<Shape>> shapes; shapes.push_back(std::make_unique<Circle>("Red", 5.0)); shapes.push_back(std::make_unique<Triangle>("Blue", 3.0, 4.0, 5.0)); for (const auto& shape : shapes) { shape->printInfo(); // Dynamic dispatch via vtable } return 0; }

Key C++ rules:

Without virtual, C++ uses static binding (base class method always called)
Always declare destructors virtual in polymorphic base classes
Use override keyword to catch typos and signature mismatches
Pure virtual functions (= 0) make a class abstract

Python Implementation

Python uses dynamic dispatch by default — all methods are virtual:

Example

from abc import ABC, abstractmethod import math class Shape(ABC): def __init__(self, color: str): self.color = color @abstractmethod def area(self) -> float: pass @abstractmethod def perimeter(self) -> float: pass def print_info(self): """Uses polymorphic calls to area() and perimeter()""" print(f"{self.__class__.__name__} [{self.color}]") print(f" Area: {self.area():.2f}") print(f" Perimeter: {self.perimeter():.2f}") class Circle(Shape): def __init__(self, color: str, radius: float): super().__init__(color) self.radius = radius def area(self) -> float: return math.pi * self.radius ** 2 def perimeter(self) -> float: return 2 * math.pi * self.radius class Square(Shape): def __init__(self, color: str, side: float): super().__init__(color) self.side = side def area(self) -> float: return self.side ** 2 def perimeter(self) -> float: return 4 * self.side # Polymorphism in action shapes = [Circle("Red", 5), Square("Blue", 4), Circle("Green", 3)] for shape in shapes: shape.print_info() # Python always uses dynamic dispatch

Design Patterns Using Runtime Polymorphism

Strategy Pattern

Runtime polymorphism enables swapping algorithms at runtime:

java example

interface SortStrategy {
    void sort(int[] data);
}

class QuickSort implements SortStrategy {
    @Override
    public void sort(int[] data) { /* quicksort implementation */ }
}

class MergeSort implements SortStrategy {
    @Override
    public void sort(int[] data) { /* mergesort implementation */ }
}

class Sorter {
    private SortStrategy strategy;  // Base type reference
    
    public void setStrategy(SortStrategy s) { this.strategy = s; }
    
    public void performSort(int[] data) {
        strategy.sort(data);  // Dynamic dispatch picks the right algorithm
    }
}

Template Method Pattern

The base class defines the algorithm skeleton, derived classes fill in the steps:

java example

abstract class DataProcessor {
    // Template method - defines the algorithm
    public final void process() {
        readData();       // Polymorphic call
        transformData();  // Polymorphic call
        writeOutput();    // Polymorphic call
    }
    
    protected abstract void readData();
    protected abstract void transformData();
    protected abstract void writeOutput();
}

Rules of Method Overriding

Rule	Java	C++	Python
Same method signature required	✓	✓	✓
Return type	Same or covariant	Same or covariant	Any (duck typing)
Access modifier	Same or wider	Same	N/A
Virtual by default	✓ (all methods)	✗ (need `virtual`)	✓ (all methods)
Can override static methods	✗ (hidden, not overridden)	✗	✗
Can override final/sealed methods	✗	✗ (`final`)	Technically yes
Annotation/keyword	`@Override` (optional)	`override` (optional)	None needed

Common Pitfalls

Pitfall 1: Calling Virtual Methods in Constructors

java example

class Parent {
    Parent() {
        display();  // DANGER: Calls Parent.display(), not Child.display()
    }
    void display() { System.out.println("Parent"); }
}

class Child extends Parent {
    private String name = "Child";
    
    @Override
    void display() { System.out.println(name); }  // name is still null here!
}

new Child();  // Prints "null" — object not fully constructed yet

Rule: Never call overridable methods from constructors.

Pitfall 2: Forgetting Virtual Destructor (C++)

cpp example

class Base {
    // ~Base() {}  // BUG: Non-virtual destructor with polymorphic class
    virtual ~Base() {}  // CORRECT: Always virtual for polymorphic classes
};

Pitfall 3: Accidental Hiding Instead of Overriding

cpp example

class Base {
    virtual void process(int x) { }
};

class Derived : public Base {
    void process(double x) { }  // This HIDES, not overrides! Different signature
    void process(int x) override { }  // This correctly overrides
};

Performance Considerations

Dynamic dispatch has a small runtime cost:

vtable lookup: Extra pointer dereference (typically 1-2 nanoseconds)
Cannot be inlined: Virtual calls prevent compiler optimization
Cache impact: Indirect calls may cause instruction cache misses

For most applications, this overhead is negligible. Only optimize away polymorphism in extremely performance-critical inner loops (millions of calls per second).

Interview Questions

Q1: What is the difference between method overloading and method overriding?

Answer: Overloading is compile-time polymorphism — same method name with different parameter types/counts in the same class. The compiler resolves which version to call based on arguments. Overriding is runtime polymorphism — same method signature redefined in a derived class. The JVM/runtime resolves which version to call based on the actual object type at runtime.

Q2: How does the JVM implement dynamic dispatch internally?

Answer: The JVM uses a virtual method table (vtable) for each class. Every object has a pointer to its class's vtable. When a virtual method is called, the JVM follows the vtable pointer, looks up the method's index in the table, and jumps to the function address stored there. This allows O(1) method resolution regardless of inheritance depth.

Q3: Can you override a static method?

Answer: No. Static methods belong to the class, not to instances, so there is no object type to determine at runtime. In Java, if a subclass defines a static method with the same signature as the parent, it's called method hiding — the version called depends on the reference type, not the object type. This is resolved at compile time.

Q4: Why should destructors be virtual in C++ polymorphic classes?

Answer: When you delete an object through a base class pointer (delete basePtr), a non-virtual destructor calls only the base class destructor, causing memory leaks in derived class resources. A virtual destructor ensures the correct derived class destructor is called first, followed by base class destructors in reverse order of construction.

Q5: Explain the `super` keyword in the context of method overriding.

Answer: super allows a derived class to call the parent's version of an overridden method. This is useful when you want to extend the parent's behavior rather than completely replace it. For example, super.save() might handle basic persistence while the override adds validation before calling super.

Quick Revision Notes

Runtime Polymorphism = Correct method chosen at runtime based on actual object type
Virtual Function = Method that can be overridden and uses dynamic dispatch
vtable = Per-class table of function pointers for virtual method resolution
Late Binding = Method address resolved during execution, not compilation
@Override = Annotation that tells compiler to verify the method actually overrides
Abstract Method = Must be overridden; class cannot be instantiated directly
Covariant Return = Override can return a more specific type than parent
Never call virtual methods in constructors — object not fully constructed

Summary

Method overriding is not just about redefining methods — it is the mechanism that powers runtime polymorphism, enabling flexible and extensible software design. Through virtual functions, vtables, and dynamic dispatch, programs can work with abstract interfaces while the correct implementation is selected automatically at runtime. This principle underlies every major design pattern and framework in object-oriented programming.

Introduction

Understanding Runtime vs Compile-Time Polymorphism

Polymorphism means "many forms." In OOP, it manifests in two ways:

Aspect	Compile-Time (Static)	Runtime (Dynamic)
Mechanism	Method overloading	Method overriding
Binding	Early binding (at compile time)	Late binding (at runtime)
Decision based on	Method signature (parameters)	Actual object type
Performance	Faster (resolved at compile time)	Slight overhead (vtable lookup)
Flexibility	Limited	Highly extensible
Keyword	Same method name, different params	`virtual`/`override`/`@Override`

Runtime polymorphism through method overriding allows you to write code that works with base class references but automatically calls the correct derived class implementation.

How Dynamic Dispatch Works

When you call an overridden method through a base class reference, the runtime system determines which implementation to execute:

java example

// The magic of runtime polymorphism
Animal animal = new Dog();  // Reference type: Animal, Object type: Dog
animal.speak();             // Calls Dog's speak(), NOT Animal's speak()

// The compiler doesn't know which speak() to call at compile time
// The JVM resolves this at RUNTIME based on the actual object

The Virtual Method Table (vtable)

Most languages implement dynamic dispatch using a vtable — a lookup table of method pointers that each object carries:

fields (name, age, etc.)		speak() → Dog.speak
		eat() → Animal.eat
fields (name, age, etc.)		speak() → Cat.speak
		eat() → Animal.eat

When animal.speak() is called, the runtime:

Follows the object's vtable pointer
Looks up the speak() entry in the vtable
Calls the function at that address

This is why it's called "late binding" — the actual method address isn't known until the program runs.

Implementing Runtime Polymorphism

Java Implementation

Example

C++ Implementation with Virtual Functions

In C++, you must explicitly declare methods as virtual to enable dynamic dispatch:

Example

Key C++ rules:

Without virtual, C++ uses static binding (base class method always called)
Always declare destructors virtual in polymorphic base classes
Use override keyword to catch typos and signature mismatches
Pure virtual functions (= 0) make a class abstract

Python Implementation

Python uses dynamic dispatch by default — all methods are virtual:

Example

Design Patterns Using Runtime Polymorphism

Strategy Pattern

Runtime polymorphism enables swapping algorithms at runtime:

java example

interface SortStrategy {
    void sort(int[] data);
}

class QuickSort implements SortStrategy {
    @Override
    public void sort(int[] data) { /* quicksort implementation */ }
}

class MergeSort implements SortStrategy {
    @Override
    public void sort(int[] data) { /* mergesort implementation */ }
}

class Sorter {
    private SortStrategy strategy;  // Base type reference
    
    public void setStrategy(SortStrategy s) { this.strategy = s; }
    
    public void performSort(int[] data) {
        strategy.sort(data);  // Dynamic dispatch picks the right algorithm
    }
}

Template Method Pattern

The base class defines the algorithm skeleton, derived classes fill in the steps:

java example

abstract class DataProcessor {
    // Template method - defines the algorithm
    public final void process() {
        readData();       // Polymorphic call
        transformData();  // Polymorphic call
        writeOutput();    // Polymorphic call
    }
    
    protected abstract void readData();
    protected abstract void transformData();
    protected abstract void writeOutput();
}

Rules of Method Overriding

Rule	Java	C++	Python
Same method signature required	✓	✓	✓
Return type	Same or covariant	Same or covariant	Any (duck typing)
Access modifier	Same or wider	Same	N/A
Virtual by default	✓ (all methods)	✗ (need `virtual`)	✓ (all methods)
Can override static methods	✗ (hidden, not overridden)	✗	✗
Can override final/sealed methods	✗	✗ (`final`)	Technically yes
Annotation/keyword	`@Override` (optional)	`override` (optional)	None needed

Common Pitfalls

Pitfall 1: Calling Virtual Methods in Constructors

java example

class Parent {
    Parent() {
        display();  // DANGER: Calls Parent.display(), not Child.display()
    }
    void display() { System.out.println("Parent"); }
}

class Child extends Parent {
    private String name = "Child";
    
    @Override
    void display() { System.out.println(name); }  // name is still null here!
}

new Child();  // Prints "null" — object not fully constructed yet

Rule: Never call overridable methods from constructors.

Pitfall 2: Forgetting Virtual Destructor (C++)

cpp example

class Base {
    // ~Base() {}  // BUG: Non-virtual destructor with polymorphic class
    virtual ~Base() {}  // CORRECT: Always virtual for polymorphic classes
};

Pitfall 3: Accidental Hiding Instead of Overriding

cpp example

class Base {
    virtual void process(int x) { }
};

class Derived : public Base {
    void process(double x) { }  // This HIDES, not overrides! Different signature
    void process(int x) override { }  // This correctly overrides
};

Performance Considerations

Dynamic dispatch has a small runtime cost:

vtable lookup: Extra pointer dereference (typically 1-2 nanoseconds)
Cannot be inlined: Virtual calls prevent compiler optimization
Cache impact: Indirect calls may cause instruction cache misses

For most applications, this overhead is negligible. Only optimize away polymorphism in extremely performance-critical inner loops (millions of calls per second).

Interview Questions

Q1: What is the difference between method overloading and method overriding?

Q2: How does the JVM implement dynamic dispatch internally?

Q3: Can you override a static method?

Q4: Why should destructors be virtual in C++ polymorphic classes?

Q5: Explain the `super` keyword in the context of method overriding.

Quick Revision Notes

Runtime Polymorphism = Correct method chosen at runtime based on actual object type
Virtual Function = Method that can be overridden and uses dynamic dispatch
vtable = Per-class table of function pointers for virtual method resolution
Late Binding = Method address resolved during execution, not compilation
@Override = Annotation that tells compiler to verify the method actually overrides
Abstract Method = Must be overridden; class cannot be instantiated directly
Covariant Return = Override can return a more specific type than parent
Never call virtual methods in constructors — object not fully constructed

Introduction

Understanding Runtime vs Compile-Time Polymorphism

How Dynamic Dispatch Works

The Virtual Method Table (vtable)

Implementing Runtime Polymorphism

Java Implementation

C++ Implementation with Virtual Functions

Python Implementation

Design Patterns Using Runtime Polymorphism

Strategy Pattern

Template Method Pattern

Rules of Method Overriding

Common Pitfalls

Pitfall 1: Calling Virtual Methods in Constructors

Pitfall 2: Forgetting Virtual Destructor (C++)

Pitfall 3: Accidental Hiding Instead of Overriding

Performance Considerations

Interview Questions

Q1: What is the difference between method overloading and method overriding?

Q2: How does the JVM implement dynamic dispatch internally?

Q3: Can you override a static method?

Q4: Why should destructors be virtual in C++ polymorphic classes?

Q5: Explain the super keyword in the context of method overriding.

Quick Revision Notes

Summary

Continue learning this concept

Introduction

Understanding Runtime vs Compile-Time Polymorphism

How Dynamic Dispatch Works

The Virtual Method Table (vtable)

Implementing Runtime Polymorphism

Java Implementation

C++ Implementation with Virtual Functions

Python Implementation

Design Patterns Using Runtime Polymorphism

Strategy Pattern

Template Method Pattern

Rules of Method Overriding

Common Pitfalls

Pitfall 1: Calling Virtual Methods in Constructors

Pitfall 2: Forgetting Virtual Destructor (C++)

Pitfall 3: Accidental Hiding Instead of Overriding

Performance Considerations

Interview Questions

Q1: What is the difference between method overloading and method overriding?

Q2: How does the JVM implement dynamic dispatch internally?

Q3: Can you override a static method?

Q4: Why should destructors be virtual in C++ polymorphic classes?

Q5: Explain the super keyword in the context of method overriding.

Quick Revision Notes

Summary

Continue learning this concept

Q5: Explain the `super` keyword in the context of method overriding.

Q5: Explain the `super` keyword in the context of method overriding.