Why is method/field hiding considered a code smell, and what design guidance follows from how Java resolves hidden members?

## Why hiding is a smell **Hiding** (static methods and fields) and **overriding** (instance methods) are written almost identically — a subclass member with the same name as a superclass one — but resolve by **opposite** rules: - **Overriding** ⇒ chosen by the object's **runtime type** (dynamic dispatch). Upcasting to the supertype still runs the subtype's behavior. This is *substitutable* and predictable. - **Hiding** ⇒ chosen by the expression's **compile-time (declared) type** (static binding). Upcasting *changes* which member you get. Because the two look the same in code, a reader naturally assumes polymorphism. When the member is actually hidden, the behavior flips on upcast — the **principle of least surprise** is violated, and the bug is invisible at the call site. ### The Liskov-substitution angle The **Liskov Substitution Principle (LSP)** says a subtype must be usable anywhere its supertype is expected, without changing correctness. Hiding undermines this: a `Parent`-typed variable holding a `Child` can read the parent's field or run the parent's static method, while a `Child`-typed variable reads the child's. The *same object* behaves differently depending on the reference type, so code written against the supertype can silently diverge from the subtype's intent — a substitutability failure that dynamic dispatch (overriding) does not have. ### The library-evolution hazard Hiding also bites during evolution. If a base class is later given a new field or static method whose name happens to match one a subclass already declares, the subclass member is suddenly *hiding* the new base member (or vice versa). Because resolution is by declared type, existing callers can change behavior without any obvious source change in the subclass — a fragile-base-class problem specific to statically bound members. ### Concrete guidance 1. **Never redeclare static methods down a hierarchy.** If you need per-subtype behavior, use **instance methods** (which override) — possibly via a factory or strategy object. Always invoke statics by **class name**, never through an instance reference (which reads like a polymorphic call but isn't). 2. **Don't shadow fields.** Keep state **private** and expose it through **getters/setters**. Accessors are instance methods, so they genuinely override and dispatch dynamically — restoring the intuitive 'subclass value wins through a supertype reference' behavior. Private fields also can't be confusingly shadowed. 3. **Always write `@Override` on intended overrides.** The compiler rejects it on a static method, a signature mismatch, or a field, turning an accidental hide/typo into a compile error. 4. **Prefer composition/strategy where variation is real behavior.** If subtypes truly differ, model the difference as polymorphic behavior, not as shadowed data or static lookups. 5. **Treat any same-named static/field across a hierarchy as a review red flag.** Static analysis tools (e.g. linters, IDE inspections) can warn on field hiding and on static calls through instances — enable them. ### The underlying principle > Make the *only* same-named-member mechanism in your hierarchies be **overriding of instance methods**, which is substitutable and dispatches dynamically. Avoid the two statically bound forms (static-method hiding, field shadowing) because they break the supertype contract and surprise readers. ### Summary rule > Hiding ≠ overriding: it binds by declared type, breaks substitutability, and surprises readers. Encapsulate fields behind overridable accessors, keep statics off the hierarchy, and let `@Override` enforce the boundary.