Computer Science 161

Laboratory Exercise #5

Thursday, November 20, 2008

A note on numbering:  I have been numbering these laboratory exercises beginning with our first lab early in the term.  I have now written a brief description of that lab for record-keeping, and have labeled the file describing that lab as Lab01.htm, renumbering the subsequent laboratory exercises.

An Introduction to Inheritance in Java

For this lab you will need to copy from Hedwig the folder/Java project Inheritance01.  The file contains an Employee class and a submission.defs file (so that you can submit the exercise at the end more easily).  If you get lost at any point, the folder/Java Project InheritanceExample contains a solution to the exercise given at the end of this lab. 

The problem we want to solve today is that of a corporation with several different types of employees

• Managers about whom we want to know their employee number, name, office, and annual salary.
• Hourly workers about whom we want to know their employee number, name,  rate of pay and hours worked. 
• Programmers about whom we want to know their employee number, name, office, annual salary, and skill code.

One way to do this is to create three separate objects:

• A Manager object with fields (instance variables) for employee number, employee name, office and annual salary.
• A Hourly object with fields for employee number, employee name, rate of pay and hours worked
• A Programmer object with fields for employee number, employee name, salary, and skill code.

We can certainly do this, but it involves a bit of duplication.  Each object has its own fields for employee number and employee name!  While there may be a good reason for doing that, in many cases it is better to specify an Employee class with subclasses for Manager and Hourly.  The Employee class will hold the fields common to all employee objects (employee number and name, for example), and the other two classes will hold the additional fields required for each. 

Begin with the Employee class, for which I have written a template.  Before looking at it, remember that when we talked about the toString method, we discovered that every class we write was automatically a subclass of the Object class (from which the default toString method comes).  Although it is not required, I have made this explicit in the definition of the Manager class as follows:

    public class Employee extends Object.

The "extends Object" is understood if the class we are defining is not a subclass of some other class. I have put it here to remind us that every class not explicitly a subclass of some other class is a subclass of Object.

Take a few moments to write a constructor for Employee, and a toString method,. I have written a print method for you that uses your toString method.  The use of this in the print method is not required - simply saying toString() would work.

After you have written a constructor and a toString method, test them out by creating an employee and then printing out the object using the already written print() method.

Creating subclasses

Now that we have that working, let's create a subclass of Employee named Manager.  Go to the BlueJ work bench, and click on "New Class",  Label this class Manager, and in the class header, write

    public class Manager extends Employee

This specifies that Manager is a subclass of Employee (which is, in turn, a subclass of Object).  Add the following fields:

	private String officeNumber;  //The manager's location

	private int salary; //The manager's annual salary

We now want to create a constructor for the Manager class, and this presents our first difficulty with subclasses.  We have instance variables (fields) for officeNumber and for salary, but the instance variables for employeeNumber and employeeName are up in the corresponding Employee superclass.  We do not have direct access to those fields - even though Manager is a subclass of Employee, those variables are private and not accessible (we will learn shortly a way to deal with this in another way). 

Here is how we solve this problem.  In the constructor for Manager (which I would like you now to write), include a call to the super class Employee, but do it in the following way:

	super(empNo, empNme);

where empNo and empNme are the employee number and employee name for the manager.  In particular, this means that the signature of your constructor for Manager should have the form:

	public Manager(String empNo, String empNme, String office, int pay)

(the names of these fields are, of course, up to you)  The call to super should be at the very start of the constructor.

The call to super is a way to call a method of the super class to the class we are writing (in this case, to the constructor of the super class).  We'll see this again in a minute.  For now, please finish up the Manager class with the constructor (as described above), a toString method, and a print method much as we did with the Employee class, and try it out (there will be some things that don't work quite the way that you want them to, but we'll solve those problems in a minute).

Note that when you first compile the Manager object, the workbench gets an arrow from the Manager class to the Employee class.  This is how Java (and object oriented programming in general) indicates a subclass -> superclass relationshiop.

Fixing the toString method

You probably noticed that the toString method for the Manager object did not return the employeeNumber and the employeeName fields - those are private to the superclass.  Nor did we write accessor methods in the Employee class to get these so that we could print them (but good for you if you decided to do things this way).  An easy way to fix this problem is to remember that the superclass Employee also has a toString() method, and that we can call this in exactly the same way that we called the constructor for our superclass, adding the resulting string from toString to the start of our toString, as, for example

	return super.toString() + "\nOffice:  " + etc.