This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Originally posted by Maki Jav: Recently i was interview for a job. The interviewer asked me whether static methods get inherited? I said yes they do! He said, "really? try it"
What was I missing?
The term "inherited" is somewhat ambiguous. The child class can of course call the parent's static method (without the "ParentClass." prefex), so it is inherited in that sense.
What the interviewer was trying to ask is if static methods can be overridden. (They can't.) Simple example:
In this case ChildClass has its own staticMethod() which shadows (but doesn't override) the method of same name in ParentClass. (I prefer the term shadow but some use the term hide.)
The point is that while it is legal to write "foo.staticMethod()" it doesn't really make sense to do so. It's better to write either "ParentClass.staticMethod()" or "ChildClass.staticMethod()" since that's how the compiler handles it anyway.
[edit: I see your Albert/Human example is similar. It's not that human.getQuantity() "does not work", just that it is a call to the static method in the Human class, not in the Albert class. Since getQuantity() is static, it's the declared type of human that matters, not the actual type that is referenced at runtime.] [ September 25, 2007: Message edited by: Brian Cole ]