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.
Ted North wrote:Rules of overriding are basically:
> the access modifier cannot be more restrictive
> the overriding method can not throw any broader checked exceptions
More restrictive than what? Broader than what? Again, tell us in your own words what this code does.
The access modifier cannot be more restrictive than the original method that is being overriden and it can't throw any broader exceptions than the original method being overriden.
So, as far as what the code does...it doesnt do much of anything. There is an abstract class Tool with a primitive int variable named SKU, not sure if this can be considered an instance variable since the class is abstract. There is also an abstract method with a void return type named getSKU which is encapsulation for the abstract Tool class; a getter for the int instance variable SKU . Class Hammer is not related at all to the abstract class Tool though it has a method with the same name getSKU().
Classic case of misdirection. They make you think of inheritance when you see abstract, then hit you with something totally unrelated. Or maybe it is related in that the classes are unrelated and I should be able to recognize when inheritance plays a factor and when it doesn't? Hmmm
What? Joe Cockerspaniel is not related to Joe Cocker? How can that be, when they have the same name?!