Page 522 - Introduction to Programming with Java: A Problem Solving Approach

488 Chapter 12 Aggregation, Composition, and Inheritance
By the way, you can have a series of overriding methods; that is, you can override an overriding method. But it’s illegal to have a series of super dot prefixes chained together. In other words, in the Person/ Employee/FullTime inheritance hierarchy, suppose the Person class contains a display method that’s overridden by the Employee and FullTime classes. In the FullTime class, it would be illegal to call the Person class’s display method like this:
super.super.display();
compilation error
To call the Person class’s display method from the FullTime class, you’d have to call the Employee class’s display method, and rely on the Employee class’s display method to call the Person class’s display method.
Have you noticed that super has two different purposes? You can use super dot to call an overrid- den method, and you can also use super with parentheses (e.g., super(name);) to call a superclass’s constructor.
Return Types Must Be the Same
An overriding method must have the same return type as the method that it’s overriding. If it has a different return type, the compiler generates an error. Said another way, if a subclass and a superclass have methods with the same name, the same sequence of parameter types, and different return types, the compiler gener- ates an error.
This error doesn’t occur all that often because if you’ve got methods with the same names and sequences
of parameter types, you’ll usually also want the same return types. But you’ll see the error crop up every now
and then when you’re debugging, so be aware of it. By the way, if a subclass and a superclass have methods
Apago PDF Enhancer
with the same name and different sequences of parameter types, it doesn’t matter if the return types are the same. Why? Because such methods are not in an overriding relationship. They are different methods entirely.
12.7 Using the Person/Employee/FullTime Hierarchy
Now let’s reinforce what you’ve learned about inheritance by looking at what happens when you instanti- ate an object of the lowest-level derived type and use that object to call overridden methods and inherited methods. Figure 12.13 contains a driver for the FullTime class, and the subsequent output shows what it does. This driver instantiates a fullTimer object from the FullTime class. Then the fullTimer object calls its display method. As shown in Figure 12.12, this display method uses super to call the Employee class’s display method, which prints the fullTimer’s name and id. Then fullTimer’s display method prints the fullTimer’s salary.
In the final statement in Figure 12.13, the fullTimer object calls its getName method and prints fullTimer’s name. But wait a minute! The FullTime class does not have a getName method, and its superclass, Employee, does not have one either. The code seems to be calling a non-existent method. What’s going on here? What’s going on is inheritance—produced by those wonderful little extends clauses. Be- cause there is no explicitly defined getName method in its own FullTime class, the fullTimer object goes up its inheritance hierarchy until it finds a getName method, and then it uses that method. In this case, the first getName method found is in the Person class, so that’s the method the fullTimer object inherits and uses. There is no need to use super dot to access the getName method (but using super dot would work, in case you’re curious). If a method is not in the current class, the JVM automatically goes up the inheritance hierarchy and uses the first definition of that method it finds.
Notice that our driver did not instantiate any Employee or Person objects. It just instantiated an object from a class at the bottom of the inheritance hierarchy only. This is the way a good inheritance