Section 5.14. Inheritance

   

---

5.14 Inheritance

Inheritance in OOP means that one class can define certain attributes and behaviors, and another class can inherit those attributes and behaviors. The benefits of inheritance are manifold , but one of the primary benefits is extensibility. It promotes good system design and maximizes your possibilities for code reuse.

Classes can be subclassed. You can create a class that inherits the properties and abilities of a parent class. A common and intuitive example is found in the animal kingdom. The class Animal might be the parent class of the Dog class and the Cat class and the Monkey class. The Animal class would hold attributes and operations that are common to all animals, such as gestationPeriod , numberOfLegs , AVG_LIFE_SPAN , getWeight() , and so on.

The Cat class, a subclass of the Animal class, would hold information and define methods particular only to Cat objects. As always, you need to consider the purpose and scope of your application. Does Cat always mean a domestic cat, or might it include cougars and tigers ? You might define your classes ”and their data's visibility ”differently when creating an application for a zoo than for an animal shelter. Consider naming in the same vein ”"Cat" is probably better for the shelter application, and "Feline" might be more appropriate for the zoo.

Subclasses can also be subclassed themselves . For instance, with a Cat subclass of Animal , you could create four subclasses ” Russian Blue , Persian , Bombay , and Siamese . They would share all of the same properties of the Cat class and then define their own distinct properties specific only to that kind of cat. See Figure 5.6.

Figure 5.6. Inheritance between classes.

Consider this. In our WWWBooks case study, we've got employees and managers. We want to organize our application to optimally represent these two entities. It would cause us to write a lot of unnecessary code if we defined employee and manager separately. On the other hand, in the real world, a manager actually is also an employee of the company; as such, managers share a lot of attributes with employees . But they are a special kind of employee, like Russian Blue is a special kind of domestic cat, which in turn is a special kind of animal. Perhaps, therefore, when we create our application, we should offload all of the manager data and operations into its own Manager class, and make it a subclass of Employee . Maybe both of them should be subclasses of Worker .

A parent class is defined in UML with an arrow pointing from the subclass to the superclass (from the child to the parent).

It is good to start thinking about what aspects of your program can be abstracted up. Perhaps a more realistic example is in order. Consider our WWWBooks case study. It probably makes sense to have a placeOrder() method that works for employees, managers, and customers, instead of trying to define this separately for each. Then what works in the system in the store will also work on the Web site, because you've incorporated inheritance into your design. And if you changed merchant banks, all of your order placement code would still work after you change the code in it that hits the bank, because you've used encapsulation.

---

Top