Week 11

The Problem Of Heterogeneous Data

For example, consider the problem of maintaining a database of employee records. There are several things we might wish to record about each employee: first name, last name, department, salary, ID number, number of dependents, et cetera. How do we store the information about an employee? Some of these values are strings, some are floating point values, and some are integers. We could store them all as strings, and thereby get away with using an array of six strings to represent an employee record. But this would be awkward. In the least it would require converting back and forth between the string representation of the salary and its numeric value any time we wanted to do some calculations.

The only alternative at this point would be to use six separate variables. But that turns into a logistical headache. Whenever we want another employee, we need to declare six more variables. If we want to define a function that operates on an employee record, we would need it to take six parameters for the employee information. If the function did something that involved comparing the information for two employees it would need twelve parameters! This quickly becomes far to cumbersome to be practical.

And what if we want to store information about one hundred employees? For the same reason we couldn't create a six-cell one-dimensional array to hold a single employee, we can't create a six-hundred-cell two-dimensional array to hold the data about one hundred employees. Instead, we would need to create six separate arrays of one hundred elements each. One would hold all the first names, one all the salaries, and so on. Then, if we wanted to sort the records in order of the employees' names we would need to make sure that each time the sorting algorithm directed us to exchange two names that we make the same corresponding exchange in each of the six arrays. Otherwise the data for an employee would become erroneously attached to another employee's name.

Objects Store Heterogeneous Data

We have already been defining classes since we wrote our first Java programs, but they have been weird degenerate classes just used to act as the shells for our programs. Now we will define degenerate classes of a different sort: ones that have no methods in them, only data. In the next lecture we will put everything together and discuss classes that have both data and behavior.

// Class:   Employee
// Author:  Joshua S. Hodas
// Date:    December 1, 1996
// Purpose: To store information about an employee
 
class Employee {
 
  public String firstName, lastName;
  public String department;
  public String idNum;
  public float  salary;
  public int    numDependents;
 
}

While this looks pretty much like a series of ordinary variable declarations, the key thing to notice is that the declarations are not inside a method, but are, instead, just inside the class header. Each object of this class (sometimes refered to as an instance of the class) will have its own one of each of these variables. Therefore, they are sometimes refered to as instance variables. (Because an object of this degenerate form is alot like a record in a database, or like a form to be filled in, the instance variables are also sometimes refered to as the fields of the object.)

Employee emp1, emp2; 

emp1 = new Employee(); 

To reiterate, each time we call new Employee() we create a new object on the heap. Each such instance has room to store all six pieces of information about an employee, but the six values are stored together in a single structure accessed through the reference once it (the reference) is stored in a variable.

emp1.lastName = "Smith";
emp1.firstName = "John"; 

Organizing Your Source Code Files

As above, you can put all of the class definitions inside a single source code file. When you compile the file using javac it creates a separate .class file for each of the classes defined in the source file. Each .class files is named for the class definition which it contains. Thus, if we put the last two class definitions in a single file named Lecture12.java then typing

javac Lecture12.java 

Even though the source file was called Lecture12.java, there would not be a file called Lecture12.class. The name of the source code file does not actually make a difference. (Yes, I know we said differently earlier in the semester. That was partially to get you to stick to one naming convention.) When we want to execute the test program, we would type:

java EmployeeTest 

Note that the order of the class definitions in a single file does not matter. As with the methods within a program, the compiler will recognize the use of classes defined later in the same file since it makes multiple passes through the source file during the compilation.

In addition, if each class definition goes in its own file, then each file can be named for the class whose source code is given in the file. This allows the java compiler to perform an extra bit of magic:

When the java compiler encounters, for example, the class name Employee being used inside the EmployeeTest program, it will stop what it is doing and go looking for a file named Employee.class in the current directory and in any directories specified in the CLASSPATH environment variable. If it finds such a file, it will use the compiled code contained therein. If the compiler doesn't find the appropriate .class file, it will look to see if there is a file named Employee.java in those same directories. If there is, the compiler will compile that file to produce Employee.class, and then continue with the interrupted compilation of EmployeeTest.java.

In fact, even if the compiler finds a .class file for a class that it needs, it still checks to see if there is also a .java file for the class as well. If there is, and if the .java file has been changed since the .class file was created, then the compiler discards the .class file and recompiles the .java file. All of this happens automatically without user intervention.

Thus, if the .java files are named for the classes they define, you do not need to worry about the order in which you compile them. Otherwise, you will need to make sure you compile support classes before you compile the programs that use them.

Objects Are Passed By Reference

This can come in handy. For instance, we can shorten the last program considerably by putting the code that gets an employee's information into a method:

// Program: EmployeeTest2
// Author:  Joshua S. Hodas
// Date:    December 1, 1996
// Purpose: To demonstrate that objects pass by reference
 
import HMC.HMCSupport;
 
class EmployeeTest2 {
 
  public static void main(String args[]) {
 
    Employee emp1 = new Employee(), emp2 = new Employee();
 
    HMCSupport.out.println("Please enter data for employee 1:");
    inputEmployee(emp1);
    HMCSupport.out.println();
    HMCSupport.out.println("Please enter data for employee 2:");
    inputEmployee(emp2);
 
    HMCSupport.out.print(emp2.firstName + " " + emp2.lastName 
                         + " in the " + emp2.department 
                         + " department makes $");
    
    if (emp1.salary < emp2.salary) 
      HMCSupport.out.print((emp2.salary - emp1.salary) + " more ");
    else 
      HMCSupport.out.print((emp1.salary - emp2.salary) + " less ");
    
    HMCSupport.out.println("per year than " + emp1.firstName 
                           + " " + emp1.lastName + " in the " 
                           + emp1.department + " department.");
  }
 


 
public static void inputEmployee(Employee emp) {
                
    HMCSupport.out.print("Last Name: ");
    emp.lastName = HMCSupport.in.nextWord();
    HMCSupport.out.print("First Name: ");
    emp.firstName = HMCSupport.in.nextWord();
    HMCSupport.out.print("Department: ");
    emp.department = HMCSupport.in.nextWord();
    HMCSupport.out.print("ID Number: ");
    emp.idNum = HMCSupport.in.nextWord();
    HMCSupport.out.print("Salary: ");
    emp.salary = HMCSupport.in.nextFloat();
    HMCSupport.out.print("Number of Dependents: ");
    emp.numDependents = HMCSupport.in.nextInt();
 
  }
}

Note that we have not included the definition of the Employee class in this program. We assume it has been placed in its own file in an accessible directory.

Returning Objects From Methods

The next program is identical to the last one, except that the inputEmployee method has been modified to allocate an Employee object, fill it in, and return it, rather than filling in the fields of an object it receives as a parameter.

Is this a good idea? Perhaps. It does remove the need for the two allocation steps in the main method. On the other hand it will not allow us to use the method to overwite the values in an existing object's fields, since it allocates its own new objects.

// Program: EmployeeTest3
// Author:  Joshua S. Hodas
// Date:    November 11, 1998
// Purpose: To demonstrate returning objects from methods
 
import HMC.HMCSupport;
 
class EmployeeTest3 {
 
  public static void main(String args[]) {
 
    Employee emp1, emp2;
 
    HMCSupport.out.println("Please enter data for employee 1:");
    emp1 = inputEmployee();
    HMCSupport.out.println();
    HMCSupport.out.println("Please enter data for employee 2:");
    emp2 = inputEmployee();
 
    HMCSupport.out.print(emp2.firstName + " " + emp2.lastName 
                         + " in the " + emp2.department 
                         + " department makes $");
    
    if (emp1.salary < emp2.salary) 
      HMCSupport.out.print((emp2.salary - emp1.salary) + " more ");
    else 
      HMCSupport.out.print((emp1.salary - emp2.salary) + " less ");
    
    HMCSupport.out.println("per year than " + emp1.firstName 
                           + " " + emp1.lastName + " in the " 
                           + emp1.department + " department.");
  }
 


  public static Employee inputEmployee() {
 
    Employee emp = new Employee();
 
    HMCSupport.out.print("Last Name: ");
    emp.lastName = HMCSupport.in.nextWord();
    HMCSupport.out.print("First Name: ");
    emp.firstName = HMCSupport.in.nextWord();
    HMCSupport.out.print("Department: ");
    emp.department = HMCSupport.in.nextWord();
    HMCSupport.out.print("ID Number: ");
    emp.idNum = HMCSupport.in.nextWord();
    HMCSupport.out.print("Salary: ");
    emp.salary = HMCSupport.in.nextFloat();
    HMCSupport.out.print("Number of Dependents: ");
    emp.numDependents = HMCSupport.in.nextInt();
 
    return emp;
  }
}

Arrays Of Objects

Employee[] employeeDatabase; 

employeeDatabase = new Employee[100]; 

Employee[] employeeDatabase = new Employee[100]; 

for (int i = 0 ; i < employeeDatabase.length ; i++) {
 
   employeeDatabase[i] = new Employee();
    
}

employeeDatabase[36].salary = 23456.78; 

Arrays Within Objects

public float[] salaryHistory = new float[10]; 

emp1.salaryHistory[1] = 34567.89; 

employeeDatabase[36].salaryHistory[1] = 34567.89; 

employeeDatabase 

employeeDatabase[36] 

employeeDatabase[36].salaryHistory 

employeeDatabase[36].salaryHistory[1] 

Objects Within Objects

// Class:   Date
// Author:  Joshua S. Hodas
// Date:    December 1, 1996
// Purpose: To store a date
 
class Date {
 
  public String month;
  public int day;
  public int year;
 
}

With this we can add the following declarations to the Employee class definition:

public Date birthDate = new Date();
public Date hireDate = new Date(); 

// Class:   Employee
// Author:  Joshua S. Hodas
// Date:    December 1, 1996
// Purpose: To store information about an employee
 
class Employee {
 
  public String  firstName, lastName;
  public String  department;
  public String  idNum;
  public float   salary;
  public int     numDependents;
  public float[] salaryHistory = new float[10];
  public Date    birthDate = new Date();
  public Date    hireDate = new Date();
 
}

Because we included the call to new in each of these date field declarations, when a new Employee object is allocated, its component Date objects will also be allocated at the same time. Otherwise we would need to allocate those fields manually after the Employee was allocated.

To access the individual fields of a Date you follow the usual rules of identifying the variable holding the Date object, and then appending a period followed by the name of the field you wish to access. Just because these Date objects in this case are not in stand-alone variables, but rather fields of a larger object, does not make their usage any different. So, given the employee variables and arrays created in the earlier examples, we could now use their Date fields as in the following examples:

emp1.birthDate.month = "April";
employeeDatabase[36].hireDate.year = 1993; 

We can also refer to the entire date object stored in one of these fields. If we knew, for instance, that employeeDatabase[32] was hired on the same date that emp1 was born, then we could set this information in the record by writing:

employeeDatabase[32].hireDate = emp1.birthDate;  

employeeDatabase[32].hireDate.year = emp1.birthDate.year;
employeeDatabase[32].hireDate.month = emp1.birthDate.month;
employeeDatabase[32].hireDate.day = emp1.birthDate.day;