What is Function Overriding vs Shadowing?
Overriding vs shadowing explained — dynamic dispatch for instance methods vs compile-time resolution for static members and fields, with Java code.
Expected Interview Answer
Overriding replaces a parent’s virtual method implementation such that the subclass version runs even when called through a base-type reference, while shadowing (hiding) merely declares a new member with the same name that is chosen based on the reference’s declared compile-time type, not the object’s actual runtime type.
Overriding requires the base method to be virtual (or, in Java, simply non-static and non-final — all instance methods are virtual by default), an identical signature, and a compatible return type; the dispatch mechanism resolves the call through the vtable using the object’s actual runtime type, so a base reference to a derived object still invokes the derived override. Shadowing happens with static methods, fields, and static/non-virtual member variables: writing a same-named static method in a subclass does not override anything — it hides the parent’s static method for calls made through the subclass’s declared type, but a call through a variable statically typed as the parent still resolves to the parent’s version at compile time, regardless of what object it actually references. This is exactly why Java documentation insists 'fields and static methods are not polymorphic' — only instance method overriding is truly dynamic; everything else is resolved at compile time based on the declared (static) type of the reference.
- Clarifies why static methods cannot achieve runtime polymorphism
- Explains a classic gotcha: accessing a shadowed field via a base reference gives the base value
- Distinguishes @Override-eligible members from those that merely hide
- Prevents bugs from assuming all same-named subclass members behave polymorphically
AI Mentor Explanation
A specific bowler's bowl() action is truly overridden when the umpire watches the actual player currently on the crease — no matter what the scorecard label says, the umpire sees the real bowler and applies the real bowler's actual technique. But a team's printed “house style” sign in the dugout is shadowing: if a junior team hangs a new sign with the same title as the senior team's sign, anyone reading from “the junior dugout” sees the new sign, while anyone still reading from “the senior dugout” sign continues seeing the old text regardless of who's actually playing. Overriding follows the real player at runtime; shadowing follows whichever sign you're looking at, decided in advance.
Step-by-Step Explanation
Step 1
Identify the member kind
Instance methods are virtual by default in Java/C# and overridable; static methods and fields are not.
Step 2
Overriding: same signature, dynamic dispatch
A subclass instance method with an identical signature replaces the parent implementation for calls resolved by the object's actual runtime type.
Step 3
Shadowing: same name, static resolution
A same-named static method or field in a subclass is resolved by the reference's declared compile-time type, not the object's real type.
Step 4
Test with a base-typed reference
Assign a subclass object to a base-typed variable and call/access the member — if the result changes based on the object, it's overriding; if it stays fixed by the variable's declared type, it's shadowing.
What Interviewer Expects
- Correct distinction: dynamic dispatch (overriding) vs static/compile-time resolution (shadowing)
- Concrete example showing a base reference to a subclass instance behaving differently for methods vs static members/fields
- Awareness that fields are never polymorphic in Java, even instance fields (they are shadowed, not overridden)
- Mention of @Override annotation catching accidental shadowing/signature mismatches at compile time
Common Mistakes
- Assuming instance fields are polymorphic like instance methods (they are always shadowed, resolved by declared type)
- Believing static methods can be truly overridden — they can only be hidden/shadowed
- Confusing shadowing with overloading (shadowing is same signature/name in different scope, overloading is different signature same scope)
- Not realizing a subclass field with the same name as a parent field is a completely separate variable, not a replacement
Best Answer (HR Friendly)
“Overriding is when a subclass truly replaces a method's behavior, and the program always picks the right version based on the actual object at runtime — even if you're holding it through a variable declared as the parent type. Shadowing looks similar on the surface but only applies to static methods and fields: which version you get depends on how the variable was declared in your code, not what object it actually points to. It's a classic interview trap because they look identical until you test them through a base-typed reference.”
Code Example
class Parent {
static String label = "Parent-label"; // shadowed, not overridden
void greet() { System.out.println("Parent greet"); } // overridden
}
class Child extends Parent {
static String label = "Child-label"; // hides Parent.label
@Override
void greet() { System.out.println("Child greet"); } // true override
}
Parent p = new Child();
p.greet(); // "Child greet" -> dynamic dispatch uses actual object type
System.out.println(p.label); // "Parent-label" -> static field resolved by declared typeFollow-up Questions
- Why are instance fields in Java always shadowed and never truly overridden?
- What compiler error would @Override catch if a subclass “override” actually has a mismatched signature?
- How does shadowing apply to static methods called via ClassName.method() versus instance.method()?
- Can a subclass shadow a private method of its parent, and why is that different from overriding?
MCQ Practice
1. Which of the following is resolved using the actual runtime type of the object?
Only instance method overriding uses dynamic dispatch based on the object's real runtime type; fields and static members are resolved by declared type.
2. A subclass declares a static method with the same signature as a static method in its parent. This is called?
Static methods cannot be overridden; a same-named static method in a subclass merely hides (shadows) the parent's version.
3. Given Parent p = new Child(); where both classes declare an instance field “x”, what does p.x return?
Fields are always shadowed, never overridden — access through a Parent-typed reference always resolves to Parent's field.
Flash Cards
Overriding in one line? — Subclass instance method replaces parent behavior, resolved by the object's actual runtime type.
Shadowing in one line? — A same-named static method or field is resolved by the reference's declared compile-time type, not the real object.
Are fields ever polymorphic? — No — fields are always shadowed in Java, never dynamically dispatched.
Quick test for which is which? — Assign a subclass object to a base-typed variable; if the result changes with the object, it's overriding, otherwise shadowing.