Polymorphism Questions Explained

Polymorphism means many shapes behind one name. The loop above holds references of type Shape, and each one points at a different runtime object. When the loop calls area, the program does not ask what the reference's declared type is; it asks what the object actually is, and it dispatches to the Circle implementation or the Square implementation accordingly. The total area printed is 21.57.

public class Main {
    public static void main(String[] args) {
        java.util.List<Shape> shapes = new java.util.ArrayList<>();
        shapes.add(new Circle(2.0));
        shapes.add(new Square(3.0));
        double total = 0;
        for (Shape s : shapes) {
            total += s.area();
        }
        System.out.println("total area = " + String.format("%.2f", total));
    }
}

abstract class Shape {
    abstract double area();
}

class Circle extends Shape {
    private final double radius;
    Circle(double radius) { this.radius = radius; }
    double area() { return Math.PI * radius * radius; }
}

class Square extends Shape {
    private final double side;
    Square(double side) { this.side = side; }
    double area() { return side * side; }
}

The mechanism is dynamic method dispatch, and it is what makes the loop possible. The compiler checks that Shape has an area method and generates a call site that looks the method up in the object's actual class at run time. The same reference type can therefore point at any implementation of the contract, and the code that uses it never has to be edited when a new implementation appears.

Notice that the loop contains no if statements. That is the payoff. A version that branched on the runtime type would need editing every time a new shape was added, and the branch would spread to every place that handled shapes. Polymorphism moves that decision to the class that owns the behaviour.

The trade-off worth naming is that the reader has to open the implementation to know what will run. For a small program that indirection can cost more than it saves, so polymorphism earns its keep when there are several implementations, or when the count is expected to grow.

Polymorphism means the same operation behaves differently depending on the actual object it is applied to, even though the call site looks identical. In code it usually shows up as a variable of a general type holding different concrete objects, and a method call that resolves to the right implementation at run time.

It is worth designing for because it removes branching from the places that consume behaviour. A loop, a handler, or a business rule that works against a general type does not need to know which concrete classes exist, and adding a new one does not require touching any of them. That property is what keeps a codebase changeable as it grows.

A plain-language version for a non-technical interviewer: it lets one instruction mean the right thing for every kind of object, so the instructions do not have to be rewritten whenever a new kind is added. New objects join the existing instruction rather than forcing the instruction to learn about them.

The everyday example is a notification going out by email, SMS or push. The code that triggers the notification does not branch on the channel. Each channel knows how to deliver itself, and the trigger stays the same no matter how many channels exist.

Because inheritance carries an obligation. Every subclass inherits a contract from its parent, and existing code is entitled to rely on that contract holding for any instance of the parent type. When you add a subclass, you are not adding a new thing in isolation; you are making a promise to every caller that already accepts the parent type.

Breakage happens in several predictable ways. Overriding a method and changing its meaning, or returning something narrower than callers assume, breaks the substitutability the parent promised. Overriding a method to throw an exception, because the child cannot support the parent's behaviour, breaks it too. A subtler case is a parent that grows a new method later: every existing subclass suddenly fails to compile, and the hierarchy becomes expensive to evolve.

The design defences are all about keeping the contract narrow and stable. Declare the parent's methods in terms of what the caller needs, keep the parent's state minimal so subclasses depend on as little as possible, avoid protected mutable fields, and prefer composition so new behaviour means a new collaborator rather than a new subclass. Also resist the temptation to add a method to a widely implemented parent; adding capability to a small, focused interface is far cheaper.

The honest summary is that inheritance couples parent and child for life, while composition keeps them independent. Every new subclass is a chance to break code you did not write, so the design should make sure that adding a subclass is genuinely rare.