Page 564 - Introduction to Programming with Java: A Problem Solving Approach
P. 564
530 Chapter 13 Inheritance and Polymorphism
/****************************************************
*
Hourly.java
Dean & Dean
This class implements an employee paid by the hour.
****************************************************/
*
*
*
public class Hourly extends Employee
{
}
// end class Hourly
private double hourlyRate;
private double hours = 0.0;
//*************************************************
public Hourly(String name, double rate)
{
super(name);
hourlyRate = rate;
// end constructor
//*************************************************
}
public double getPay()
{
}
double pay = hourAlypRaateg*ohouPrsD; F Enhancer hours = 0.0;
return pay;
// end getPay
//*************************************************
public void addHours(double hours)
{
this.hours += hours;
} // end addHours
Figure 13.12
Hourly class
in these two classes are both simple, but they are different. To keep the JVM from selecting the dummy
getPay method in the base class during dynamic binding, all derived classes should override that method. 13.8 abstract Methods and Classes
The dummy getPay method in Figure 13.10 is an example of a kludge (pronounced “klooj”). Kludgy code is ugly inelegant code that provides a workaround for a problem. Usually, inelegant code is hard to under- stand. And hard-to-understand code is hard to maintain. So try to avoid kludges. Sometimes that’s not pos- sible, but in this case we can indeed avoid the dummy-method kludge. Here’s how. . . .
