Overloading vs Overriding - Quiz

Method overriding is declaring a method in a subclass with the same name and the same parameter list as an inherited method of the superclass, so that the subclass supplies its own implementation.

Which implementation runs is decided by the JVM at runtime from the type of the object, not from the type of the variable. This mechanism is called dynamic method dispatch, or late binding, and it is the way Java implements runtime polymorphism.

class Toy {
    public void printName() {
        System.out.println("Toy");
    }
}

class Doll extends Toy {
    @Override
    public void printName() {
        System.out.println("Doll");
    }
}

Toy doll = new Doll();
doll.printName();   // prints "Doll"

The declared type Toy controls only which methods may be called; the real object Doll controls which implementation executes.

The compiler accepts a method as an override only if all of the following hold:

1. Name and parameter list. Both must match the superclass method exactly — same types, same order, same count. If the parameter list differs, you get an overload, not an override.

2. Return type. The same type, or a subtype of it (a covariant return, allowed since Java 5). Widening the return type is a compile error.

3. Access modifier. May be widened (protected → public), never narrowed — otherwise the compiler reports "attempting to assign weaker access privileges".

4. Checked exceptions. May be dropped or narrowed, never added or broadened. Unchecked exceptions (RuntimeException, Error) are not restricted.

5. Inheritance. Only inherited instance methods can be overridden, so static, final, private methods and constructors are excluded. An abstract method must be implemented unless the subclass is abstract too.

Overloading means several methods share one name inside a class but take different parameter lists; the compiler picks the target from the declared types of the arguments. Overriding means a subclass redeclares an inherited method with exactly the same name and parameter list; the JVM picks the implementation from the actual type of the object.

The single criterion to remember: overloading is resolved by the compiler, overriding by the JVM at runtime.

Overriding lives in classes related by inheritance, keeps the parameter list identical, allows only the same or a covariant return type, may widen but never narrow access, may not broaden checked exceptions, accepts @Override, and is runtime polymorphism.

Overloading usually lives in one class, requires a different parameter list, allows any return type once the parameters already differ, allows any access modifier and any exceptions, rejects @Override, and is compile-time polymorphism. static, final, private methods and constructors cannot be overridden but can all be overloaded.

None of them can be overridden, although all of them can be overloaded.

static. A subclass may declare a static method with the same signature, but that is method hiding, not overriding: the version to run is chosen at compile time from the reference type.

class Base {
    public static void go() { System.out.println("Base.go"); }
}

class Sub extends Base {
    public static void go() { System.out.println("Sub.go"); }
}

Base ob = new Sub();
ob.go();   // prints "Base.go" - the compiler looks at the variable type

final. A final method cannot be overridden at all (compile error "cannot override final method"), and a final class cannot even be subclassed.

private. A private method is not inherited, so a same-name method in the subclass is an independent method; @Override on it does not compile.

Constructors. They are not inherited either, so they cannot be overridden — constructors with different parameter lists are simply overloads.

With the keyword super: super.methodName(). This is the only way to reach the superclass version, because a plain call to the same name inside the subclass would recurse into the overriding method.

class Doll extends Toy {
    @Override
    public void printName() {
        super.printName();   // the Toy version runs first
        System.out.println("Doll");
    }
}

The call is allowed only inside the subclass itself and goes exactly one level up the hierarchy — there is no super.super.printName() in Java. If you need behaviour from a grandparent class, extract it into a separate method.

@Override is optional — overriding works exactly the same without it. What it adds is a compiler check: the annotated method must really override a method of a superclass or an interface, otherwise the code does not compile.

That turns a silent bug into a build error. The textbook case is equals: writing equals(User obj) instead of equals(Object obj) is an overload, so collections keep using the identity-based equals inherited from Object and the bug surfaces far from the declaration.

@Override
public boolean equals(Object obj) {   // a wrong signature now fails to compile
    ...
}

The annotation cannot be placed on an overloaded method, which makes it a reliable way to prove which of the two mechanisms you actually wrote. Since Java 6 it is also legal on methods implementing an interface; in Java 5 that was a compile error.