Method Overriding Rules

Four rules decide whether a method overrides or merely replaces a name. The name and the parameter types must match exactly. The return type must be the same or a subtype of the parent's. The visibility must be the same or wider, so a protected method cannot be replaced by a private one. And the throws clause may not add new checked exceptions, though it may declare fewer or none.

public class Main {
    public static void main(String[] args) {
        Animal a = new Dog();
        System.out.println(a.speak());
        System.out.println(a.name());
    }
}

class Animal {
    String speak() { return "generic sound"; }
    String name() { return "animal"; }
    final String id() { return "fixed"; }
}

class Dog extends Animal {
    String speak() { return "woof"; }
    // String id() { return "dog"; }     // will not compile: final method
    // private String secret() { }       // will not compile: visibility narrowed
}

The example shows a normal override and two attempts that would not compile. The speak method in Dog matches the parent's name and parameters and returns a String, so it overrides. The commented attempts show the other rules: id is final in the parent, so it cannot be overridden at all, and a method cannot be made more restricted than the one it replaces, so private would be rejected.

Two related rules round out the picture. A method marked static hides rather than overrides, and a private method is not inherited at all, so declaring a private method with the same name in a subclass is a completely separate method. Neither is an override, and both are common sources of confusion.

The static method rule deserves emphasis because it is the subtle one. If the parent method is static, the child's same-signature method hides it, and the one that runs is chosen by the reference type rather than the runtime type. If the parent method is an instance method, the child's same-signature method overrides it and the runtime type decides. Mixing the two produces an error the compiler catches, which is why the compiler can be relied on here.

Overriding means a subclass provides a new implementation of an inherited instance method with the same name and parameter types. The runtime type of the object decides which implementation runs, so the effect is dynamic dispatch. This is what lets a base-typed reference call a subclass behaviour.

Overloading means several methods on the same class share a name but differ in parameter types. The compiler picks one using the argument types at the call site, so the choice is made at compile time and does not depend on the object. Adding an overload is safe for existing callers as long as you do not create an ambiguity.

Hiding is the third case and the one people forget. It applies to static methods and to fields. A subclass that declares a static method with the same signature hides the parent's, and the reference type decides which one is called. A subclass field with the same name hides the parent's field for direct field access, which is exactly the shadowing that the this and super keywords exist to disambiguate.

A compact summary: overriding changes behaviour and is chosen at run time, overloading changes the signature and is chosen at compile time, and hiding applies to statics and fields and is chosen by the reference type.

Because the caller may hold a reference to the parent type. The caller compiled against a contract that says the method throws a particular checked exception, or throws none at all. If the subclass could add a new checked exception, every existing caller would need a catch block for an exception the compiler had promised would never happen, and code that was correct would stop compiling or, worse, would fail at run time.

The rule is that an override may declare the same checked exceptions as the parent, a subset of them, or none. Unchecked exceptions are unconstrained, because the compiler does not force callers to handle them anyway, and that is exactly why they are the usual source of nasty surprises in large codebases.

What the rule protects is substitutability. If a Square could not be used wherever a Rectangle is expected, code written against Rectangle would break, and that is precisely the promise inheritance makes. The exception rule is one of the few places where the compiler enforces that promise for you, so it is worth remembering.

There is a related design point for an interview. If a subclass genuinely needs to signal a different failure, the usual answer is not to widen the throws clause but to model the outcome explicitly, such as returning a result object that carries a failure, or by introducing a new exception type that the caller already handles at a higher level.