Aqua Phoenix
     >>  Research >>  OOP  


9. Inheritance

9.1 Summary

  • What is inheritance; how does it relate to Object Oriented Programming? Why is it useful to separate common things into a separate unit?
  • What do Textfields, Textareas, Labels, Buttons, Canvases, and Checkboxes have in common?

9.2 Contents

9.2.1 What is inheritance; how does it relate to Object Oriented Programming? Why is it useful to separate common things into a separate unit?

Let us start out with an example of a real-world type of application that we intend to develop: a user database program for a university, in which we would like to keep track of students, professors, staff, alumni, and other types of community members of a University. The question to ask is how to structure a person's data in the context of what we would like to achieve.

A first approximation of the intended structure is to make a large table, where one field acts as a type of person, e.g. professor, student, and the other fields include first, middle, last name, social security number, address, date of birth, and other generic data. Now we introduce a conflict by generating a column called "salary". In a typical scenario, a professor will have a salary, but a student will not. For a second conflict, introduce a grade point average. While a student of this University most definitely qualifies for this field, a staff member, or generic employee will in most cases not. How can we treat these cases where certain data is only available for certain individuals?

A valid answer is to keep the particular cell in the table empty for such cases. But this quick-fix is not a great way of keeping a data structure, mainly for efficiency reasons. Thus we seek a way of separating the generic data of a community member from the specific data of this person. Generic fields include: first and last name, because every person should have one; a social security number, even if it is a fake number, like those given to international students; an address, and perhaps a phone number; a date of birth; and some other fields. Now that we have identified the generic data of every individual, we want to create an object for this generic person. The object is very similar to a Rolodex card, that features the same information. Let's call the object CommunityMember, and assign appropriate placeholders for the various fields (name, SSN, DOB, etc.)

The question now is how to create a person, for instance a student with this generic object. If we took some of the student's generic data and stuffed it into the previously defined object, that would not make it a student. Thus we are looking for a way to add special fields to the previously defined object that would make it a student, without modifying the object CommunityMember though. Thus we create a second object, which we call Student. This object will then define all of the additional data for a student. At this point we introduce the concept of inheritance as the object Student contains some generic fields in the generic object CommunityMember, and some special fields in the object Student. It is appropriate to draw a diagram of a tree with CommunityMember at the root, and the Student as a leaf node below the root node with an arrow pointing to the root. This type of graph shall signify that the object Student extends, or inherits the fields of the parent node. The inheritance process thus makes all the fields of the parent node CommunityMember available to the object Student, without us having to define them in the Student object again.

In order to make some use of the inheritance, we may now want to add another object parallel to Student. An alumnus, for example, could inherit the same data from CommunityMember, and have additional fields, like Date of Death, etc. In order to extend the idea of inheritance a little, we will not simply put a Professor on the same level as student or alumnus. Since a Professor and a Staff member are types of employees, we can make an Employee object that branches from the CommunityMember. The employee could then share some data, for instance salary, type of contract, etc. However, data like "classes taught" would not apply to both Professor and Staff, thus we do want to differentiate between the two. The final graph would the look something like this:

Figure 1.1
Let's look at one of the predominant features of inheritance. If a field is added to the student body, e.g. dorm IP address, then in an inheritance model, only the Student object needs to be changed. If this particular field needed to be introduced for all community members, then it would be added to the object CommunityMember. Thus, inheritance allows for a good division of data.

Yet another feature of inheritance deals with passing arguments as different types. We have dealt with this in the type tool (int, double, char, boolean), where objects of some defined type could be casted as a different type. Casting itself is not a method that is unique to Object Oriented Programming; however, given a Student object, we can describe it either as a Student object, or as a Community Member object. For another example, take a function that accepts an integer. Then it cannot be passed a float, or a double. However, if integers, floats, and doubles all inherited a general data type called number, then a function that accepted a number as an argument could accept integers, floats, and doubles. The type number, just like the type CommunityMember, acts like a more general description of something else.

In case the concept of inheritance is not understood, we could look at geometric shapes for a more graphic example. At the root, we have an object called a Point, which implements a point in (x,y). Any object that adds one more piece of information to this one point could thus inherit the object Point. A circle, for example, is no more than a point with a radius. Thus the object Circle could extend the object Point. A second point (x2, y2) could extend the object Point to make an object Line. A third point (x3, y3) could then extend the object Line to make an object Triangle. A second radius could extend the object Circle to make an Ellipse. And so forth. This example may be simpler and easier to understand, as it follows some more logic in building a geometric shape, by adding some more detail at every step.

9.2.2 What did Textfields, Textareas, Labels, Buttons, Canvases, and Checkboxes have in common?

Similar to our University example above, Textfields, Textareas, and all of the other compontents we have discussed before, follow some kind of tree structure of inheritance. Specifically, the objects we have discussed are related as shown in the following model:

Figure 1.2
Notice the separation between common methods and component-specific methods in the tool that you have used previously. It turns out that common methods, such as setBackground(..), have been implemented in all components. These kind of methods, that exist in all subclasses, where Component is the superclass and TextField is a subclass, are said to be inherited from the superclass.