CSC108 Lecture #10 - Inheritance Example

Inheritance

Inheritance Relationships (class hierarchy tree)

                          Machine

                     /        |         \
                   /          |           \

            Appliance      Vehicle         Computer

                       /      |       \
                     /        |         \
                   /          |           \
                               
              Van            Car            Truck

             /   \          /   \            /   \
            /     \        /     \          /     \

         Mini  Delivery  Limo   Sports    Dump   Pickup

The relationship between the inherited classes shown above are "is a" relationships. For example, a Vehicle is a Machine, and a Limo is a Car. The relationship does not work in the opposite direction. Not every Vehicle is a Van, so you cannot say "a Vehicle is a Van."

This "is a" relationship translates directly into which types of inherited objects can be stored in various variables. This also applies to casting to various types of objects. For example,

  Machine a = new Machine (); // is allowed since a Machine is a Machine
  Machine b = new Vehicle (); // is allowed since a Vehicle is a Machine
  Vehicle c = new Vehicle (); // is allowed since a Vehicle is a Vehicle
  Vehicle d = new Machine (); // NOT allowed since a Machine is not a Vehicle

Each class may have have attributes (instance variables or methods). Their attributes are classified as a "has a" relationship. The Limo class "has a" toString() method, for example.

In lecture, I talked about different instance variables and methods that some of these classes might have. I said the Machine class might have a "powerType" instance variable that keeps track of the type of power needed to operate the machine. The Vehicle might have a wheelCount instance variable. There would be no need to put this variable higher in the hierarcy, because not all types of machines (a computer for example) would need a wheelCount instance variable. The Van class might have a backSeat instance variable to keep track of the number of seats beyond the standard 1st and 2nd rows of seats. There would be no need to store this higher in the hierarchy because not all Vehicles or Machines have back seats. We might put a boxLength variable in the Truck class only, as it would be used to keep track of the length of the box, which we know only applies to trucks.

In terms of methods, we might put a drive() method in the Vehicle class. We wouldn't put it in the Machine class, as not all machines drive. A toString() method could be placed in one or more classes in the hierarchy. Suppose I put a toString() method in the Vehicle class, Truck class, Limo class, and Sports class. If a Car object called the toString method, it would use the Vehicle's toString method. If a Limo object called the toString method, it would use the Limo's own toString() method. We say that the Limo class overrides the toString() method which is in its ancestor class. It may be that there is something different about how Limo's are printed that require that we need to redefine (override) this method in the Limo class.

A general rule of thumb is that the information stored higher in the hierarchy is more general because it applies to all classes below it, whereas the information stored lower in the hierarchy is more specific because it only applies to a limited number of classes.

Note that a class will inherit all attributes (instance variables and methods) from all classes that are above this class in the hierarchy. In Java, all instance variables and methods that have been declared as public or protected can be used within a subclass.