How do overriding, overloading, and method hiding differ, and how does each get resolved?

## Three mechanisms that look similar All three involve methods sharing a name, but they are governed by different rules and resolved at different times. ### 1. Overriding (runtime, instance methods) A subclass provides a new body for an inherited **instance** method with the **same signature** (name + parameters). The choice of which implementation runs is made **at runtime** by **dynamic dispatch**: the JVM looks at the object's *actual* (runtime) class, not the declared reference type. ```java class Animal { String sound() { return "..."; } } class Cat extends Animal { @Override String sound() { return "meow"; } } Animal a = new Cat(); a.sound(); // "meow" - runtime type Cat wins ``` ### 2. Overloading (compile-time, same name, different params) **Overloading** is declaring several methods with the **same name** but **different parameter lists** in the same accessible scope (same class or inherited). They are *unrelated* methods that merely share a name. The compiler selects which one to call **at compile time**, based on the **static (declared) types** of the arguments, using overload resolution (most-specific applicable method). ```java void print(int x) {} void print(Object x) {} Object o = 5; print(o); // calls print(Object) - chosen from o's STATIC type, even though it holds an Integer print(5); // calls print(int) ``` Overloading is sometimes called 'compile-time polymorphism' or 'static binding'. ### 3. Hiding (static methods and fields) **Static methods cannot be overridden.** If a subclass declares a static method with the same signature as a parent static method, it **hides** it. Hidden members are resolved by the **compile-time / reference type**, NOT the runtime object. ```java class Parent { static String who() { return "parent"; } } class Child extends Parent { static String who() { return "child"; } } Parent p = new Child(); p.who(); // "parent" - resolved by reference type Parent (hiding, not overriding) ((Child) p).who(); // "child" ``` **Fields are also hidden, never overridden.** Field access binds to the **declared type** of the reference: ```java class Parent { int x = 1; } class Child extends Parent { int x = 2; } Parent p = new Child(); p.x; // 1 - field resolved by reference type Parent ((Child) p).x; // 2 ``` ## The decisive contrast | Aspect | Overriding | Overloading | Hiding | |---|---|---|---| | What matches | same signature | same name, different params | same signature (static) / same name (field) | | Applies to | instance methods | any methods | static methods, fields | | Resolved | runtime (object type) | compile time (arg static types) | compile time (reference type) | | Polymorphic? | yes (dynamic) | no | no | ## Why @Override matters here Because overloading and a botched override look identical in source, a tiny mistake - wrong parameter type, an extra parameter, or trying to 'override' a static method - silently produces an *overload* or a *hide* instead of the override you intended, and the bug surfaces only at runtime as 'the wrong method ran'. Annotating with `@Override` makes the compiler verify you genuinely overrode an instance method; if you accidentally overloaded or targeted a static, it refuses to compile. ## Common trap ```java class Base { boolean equals(Base other) { ... } } // OVERLOAD of Object.equals, not an override! ``` This declares `equals(Base)` - a new overload - while `Object.equals(Object)` remains unoverridden. Collections calling `equals(Object)` never hit this method. `@Override` would have flagged it instantly.