Skip to main content

We all know that when a subclass provides an implementation of a method that exists in any of this class’s parent classes, it is called method overriding. Many of us also know method overriding is an example of dynamic polymorphism. But why is it dynamic polymorphism?

Let’s see an example:

public class MethodOverridingDemo {
    public static void main(String[] args) {
        Car car = new Toyota();
        car.move();
    }
}


abstract class Car {
    abstract void move();
}


class Toyota extends Car {

    @Override
    void move() {
        System.out.println("Toyota Moving");
    }
}


class Honda extends Car {
    @Override
    void move() {
        System.out.println("Honda Moving");
    }
}

In this code, I have written an abstract class Car. The classes, Toyota and Honda, extend the Car class and override the method of Car, move().

From the main() method, I refer to a child class object by a parent class reference to call move(). So what does exactly happen in compile time and runtime?

In compile time, the compiler checks if the method, move(), is callable by the parent class reference. Then the code doesn’t know which child’s overridden method is actually going to be invoked in runtime. It thinks the parent method is going to be executed as we call the method with parent class reference. So, to compile we need the overridden method (at least the abstract definition) in the parent class.

But in runtime, the code knows on which object the method is called. So it executes the exact overridden method. Hence method overriding is the runtime/dynamic polymorphism.

Now there can be another discussion that why I need to resolve it on runtime. What if the ‘intelligent’ compiler resolves it on compile time by creating a link to the method of Toyota? Well, the reason I think is given below:

The example we used here is a very basic one. We don’t use method overriding like that in real-life coding. Because, if you know you need to run move() of Toyota, why will you refer to it by a reference of Car type? You definitely can, but unnecessary to do that.

We usually don’t know which child is sent to a reference in real-life coding. For example, suppose, you have a CarService class:

public class CarService {
    public void move(Car car) {
        car.move();
    }
}

We generally use an abstraction here to remove dependency on the children of Car to call move(). When car.move() is executed, move() of any Car’s child can be invoked. It depends on the child object’s type that is sent to move() of CarService. So how will the compiler know which child’s move() needs to be linked on compile time? No option is there other than resolving on runtime.

Lead Software Engineer at Vivasoft Limited | Website | + posts

A passionate, responsible, and committed engineer with a great appetite for challenges. I am passionate about Java language and like to know in-depth about Java. Believing in knowledge sharing, I am here to help the learning smooth.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.