From ClassicOoAntiPatterns:
Beginners (in my Java experience) seem to forget that a Class has a superclass and hence inherits the methods of that superclass. This may seem trivial but the number of times I've had to answer a question like "Why hasn't a java.awt.Button got a method to tell me how big it is?", is amazing.
Is this an OO AntiPattern or a documentation AntiPattern?
It's an OO anti-pattern, unless you believe that every class comment should include a line that says "The superclass also has some stuff that might interest you". --LanceWalton
This suggests a "document reading pattern", something along the lines of The class doesn't do this? Look up and down the inheritance tree.
Similar to "Item 30: Know and use the libraries" in JoshuaBlochs EffectiveJava book -- DavidPlass
A colleague once had a class in Java that descended from JPanel, and gave it a method setName(..), overlooking the fact that it did override that method in JPanel, on which the JPanel relied. I'm rather fond of the 'override' keyword in Delphi, which forces you to think about what you're doing. It also gives you a warning if you didn't use it and are thus hiding a superclasses method. Then again, Delphi also needs you to mark every method that could possibly be needed to be overridden ever to be marked with 'virtual', which is something I'm not too crazy about -- imagine having 'final' as the default for all methods! --AalbertTorsius.
I think it's a documentation issue. When I ask Eclipse for completion on a method, it (correctly) lists all the possibilities, independent of which class in the inheritance hierarchy they come from. --Geoff Sobering
"imagine having 'final' as the default for all methods!" - oh, the horror! (sorry, couldn't resist...)