Class hierarchy

Imagine a program that has to deal with motor vehicles, including cars, trucks, and motorcycles. A Department of Motor Vehicles might use a program like this to keep track of registrations. Every vehicle has a registration number and an owner, but each type of vehicle also has details that belong only to it. A car has a number of doors, a truck has a number of axles, and a motorcycle may or may not have a sidecar.

A program could treat each vehicle type as an unrelated thing, but that would repeat the shared parts in every type. The alternative is a class hierarchy. The program uses one general class named Vehicle to represent what all vehicles have in common, and separate, more specific classes for Car, Truck, and Motorcycle. The specific classes are connected to the general class by inheritance. This lesson traces how that connection works, which members each object ends up with, and where a member reference breaks.

In the vehicle program, Vehicle sits at the top of the hierarchy as the superclass. Car, Truck, and Motorcycle sit one level below it as subclasses. Each subclass is declared with the word extends, which is what links it to its parent. The source gives these declarations in a Java-style notation, shown below as a sketch of the declarations described in the source. Only the member declarations are shown, not method bodies.

Read the diagram from the top down. Vehicle is the general class, holding the structure that all vehicles share. Each box below it is a more specific class, and each one adds a single member of its own. The hierarchy therefore states a common property once, at the broadest level, and records each difference at the narrower level where it applies. The source describes this as organizing related classes by common properties instead of treating every class as unrelated.

A subclass inherits all the fields and methods of its parent class, and also adds its own members. So an object created from Truck does not contain only the members written inside Truck. It also contains the members declared in Vehicle. Following the declarations above, the members come from two places. The inherited members come from Vehicle: registrationNumber, owner, and transferOwnership(). The member declared in Truck itself is numberOfAxles.

A member reference, such as myCar.numberOfDoors, asks the program to read a member through an object. The reference succeeds only when the member exists in the class the reference is read through. The inheritance relationship flows downward in this example. Vehicle does not declare numberOfDoors, numberOfAxles, or hasSidecar, because those belong to the subclasses. A reference that depends on a subclass-only member therefore cannot be satisfied by a plain Vehicle reference.

The diagram shows the failure point. The reference points to a real Truck object, but the reference is read through Vehicle. The field registrationNumber is declared in Vehicle, so reading it through the Vehicle reference succeeds. The field numberOfAxles is declared only in Truck, so the access fails at the moment the reference is checked against the Vehicle declarations. The source describes this as the place to start when debugging, because it is where the result diverges from what you expected.

Inheritance is not limited to copying a class unchanged. A subclass can use what it inherits, add to it, or change part of it. The source names three options: a subclass can reuse inherited properties, add new properties, or override an inherited response. Adding a member is what Car, Truck, and Motorcycle do with numberOfDoors, numberOfAxles, and hasSidecar. Overriding means defining a different response to a message the subclass has inherited.

This is also why inheritance supports software reuse. Lines, rectangles, ovals, polygons, and curves in a drawing program need separate classes, because they describe different kinds of shapes. They still share the fact that each is something the program can draw. A shared parent class records that common identity once, and each subclass records only what makes it different. When an existing class needs only small adaptations, a subclass can make those adaptations without rewriting the shared structure.