Simple rules for building a better inheritance design.
DO use inheritance when one class is a more specific type of a superclass. Example: Toyota is a more specific type of Car, Toyota extends Car makes sense.
DO consider inheritance whe you have behavior(implemented code) that should be shared among multiple classes of the same general type. Example: Cat, Dog, Horse all need to move(), sleep(), so putting that functionality in a superclass “Animal” migth make sense, and makes for easier maintenance and exttensibility. Be aware, hoever, that while inherittance is one of the key features of object-oriented programming, it’s not necessarily the best way to achieve behavior reuse.
DO NOT use inheritance just so that you can reuse code from another class, f the relationship between the superclass and subclass violate either of the above two rules. For example, imagine you wrote special printing code in the Alarm class and now you need printing code in the Piano class, so your have Piano extend Alarm so that Piano inherits the printing code. That makes no sense! A Piano is not a more spcific type of Alarm.
DO NOT use inheritance if the subclass and superclass do not pass the IS-A / HAS-A test. Always ask yourself if the subclass IS-A more specific type fo the superclass. Example: Tea IS-A Beverage makes sense. Beverage IS-A Tea does not
- A subclass extends a superclass
- A subclass inherits all public instance variables and methods of the superclass, but does not inherit the private instance variables and methods of the superclass
- Inherited methods can be overridden; instance variables cannot be overridden(although the ca be redefined in the subclass, but thtats no the same thing, and theres almost never a need to do it)
- Use the IS-A test to verify that your inheritance hierachy is valid. If X extends Y, then X IS-A Y must make sense
- The IS-A relationship works in only one direction. A hippo is an Animal, but not all Animals are Hippos
- When a method is overridden in a subclass, and that method is invoked on an instance of the subclass, the overridden version of the method is calles. (The lowest one wins)
- I f class B extends AA, and C extends B, class B IS-A class A, and class C IS-A
So what does all this inheritance really buy you?
You get a lot of OO mileage by designing with inheritance. You can get rid of duplicate code by abstracting out the behavior vommon to a group of classes, and sticking that code in a superclass. That way, when you need to modify it, you have only one place to update, and the change is magically reflected in all the classes that inherit that behavior…make the change and compile the class again. Thats it.
You dont have to touch the subclasses!
Just deliver the newly-chaged superclass, and all classes that extend it will automatically use the new version. A Java program is nothing but a pile of classes, so the subclasses dont have to be recompiled in order to use the new version of the superclass. As long as the superclass doesnt break anything for the subclass, everythings fine. Breaking means…modifying something in the superclass that the subclass is depending on, like a particular methods arguments or return tpye, or method name.
- You avoid duplicate code
Put common code in one place, and let the subclasses inherit that code from a superclass. When you want to change that behavior, you have to modify it in only one place. - You define a common protocol for a group of classes
Inheritance lets you guarantee that all classes grouped under a certain supertype have all the methods that the supertype has. In other words…”All my subclasses can do these things, with these methods that look like this”