How to Use Subclasses in Java

You can use subclasses in Java. Creating subclasses is fine, but you gain nothing from these subclasses unless you write code to use them. So here, you explore code that uses subclasses.

Now the time has come for you to classify yourself as either a type-F person, a type-P person, or a type-T person.

• A type-F person wants to see the fundamentals. (The letter F stands for fundamentals.) “Show me a program that lays out the principles in their barest, most basic form,” says the type-F person. A type-F person isn’t worried about bells and whistles. The bells come later, and the whistles may never come. If you’re a type-F person, you want to see a program that uses the FullTimeEmployee and PartTimeEmployee subclasses and then moves out of your way so that you can get some work done.
• A type-P person wants practical applications. (The letter P stands for practical.) Type-P people need to see ideas in context; otherwise, the ideas float away too quickly. “Show me a program that demonstrates the usefulness of the FullTimeEmployee and PartTimeEmployee subclasses,” says the type-P person. “I have no use for your stinking abstractions. I want real-life examples, and I want them now!”
• A type-T person wants to test the code in the FullTimeEmployee and PartTimeEmployee subclasses. Testing the code means putting the code through its paces — checking the output's accuracy when the input is ordinary, when the input is unexpected, and even when the input is completely unrealistic. What's more, the type-T person wants to use a standard, easily recognizable outline for the testing code so that other programmers can quickly understand the test results. The type-T person creates JUnit tests that use the FullTimeEmployee and PartTimeEmployee subclasses.

The code below, which is for the type-F crowd, is lean and simple and makes good bedtime reading.

If you're a type-P or type-T person, please visit allmycode.com. The site contains examples to satisfy type-P and type-T readers.

This code shows you a bare-bones program that uses the subclasses FullTimeEmployee and PartTimeEmployee. Here’s the program’s output.

public class DoPayrollTypeF {

public static void main(String args[>) {

FullTimeEmployee ftEmployee = new FullTimeEmployee();

ftEmployee.setName("Barry Burd");

ftEmployee.setJobTitle("CEO");

ftEmployee.setWeeklySalary(5000.00);

ftEmployee.setBenefitDeduction(500.00);

ftEmployee.cutCheck(ftEmployee.findPaymentAmount());

System.out.println();

PartTimeEmployee ptEmployee = new PartTimeEmployee();

ptEmployee.setName("Steve Surace");

ptEmployee.setJobTitle("Driver");

ptEmployee.setHourlyRate(7.53);

ptEmployee.cutCheck(ptEmployee.findPaymentAmount(10));

}

}

To understand this code, you need to keep an eye on three classes: Employee, FullTimeEmployee, and PartTimeEmployee.

The first half of the code deals with a full-time employee. Notice how many methods are available for use with the ftEmployee variable? For instance, you can call ftEmployee.setWeeklySalary because ftEmployee has type FullTimeEmployee. You can also call ftEmployee.setName because the FullTimeEmployee class extends the Employee class.

Because cutCheck is declared in the Employee class, you can call ftEmployee.cutCheck. But you can also call ftEmployee.findPaymentAmount because a findPaymentAmount method is in the FullTimeEmployee class.

Making types match

Look again at the first half of the code. Take special notice of that last statement — the one in which the full-time employee is actually cut a check. The statement forms a nice, long chain of values and their types. You can see this by reading the statement from the inside out:

• Method ftEmployee.findPaymentAmount is called with an empty parameter list. That’s good because the findPaymentAmount method takes no parameters.
• The findPaymentAmount method returns a value of type double.
• The double value that ftEmployee.findPaymentAmount returns is passed to method ftEmployee.cutCheck. That’s good because the cutCheck method takes one parameter of type double.

Check out the fanciful graphical illustration.

Always feed a method the value types that it wants in its parameter list.

The second half of the story

In the second half of the code, the code creates an object of type PartTimeEmployee. A variable of type PartTimeEmployee can do some of the same things a FullTimeEmployee variable can do. But the PartTimeEmployee class doesn’t have the setWeeklySalary and setBenefitDeduction methods. Instead, the PartTimeEmployee class has the setHourlyRate method. So the next-to-last line is a call to the setHourlyRate method.

The last line of the code is by far the most interesting. On that line, the code hands the number 10 (the number of hours worked) to the findPaymentAmount method. Compare this with the earlier call to findPaymentAmount — the call for the full-time employee in the first half of the code. Between the two subclasses, FullTimeEmployee and PartTimeEmployee, are two different findPaymentAmount methods. The two methods have two different kinds of parameter lists:

• The FullTimeEmployee class’s findPaymentAmount method takes no parameters.
• The PartTimeEmployee class’s findPaymentAmount method takes one int parameter.

This is par for the course. Finding the payment amount for a part-time employee isn’t the same as finding the payment amount for a full-time employee. A part-time employee’s pay changes each week, depending on the number of hours the employee works in a week. The full-time employee’s pay stays the same each week. So the FullTimeEmployee and PartTimeEmployee classes both have findPaymentAmount methods, but each class’s method works quite differently.