Programmers are really just diabolical slackers at heart. Through a charmed blend of laziness and high logical intelligence, they discover easier ways to do just about everything. They loathe redundancy, and if a piece of code were already written, it would be nothing short of sacrilege to write it again.
Some have theorized that within a few years, no one will be creating new code and the job of a programmer will be simply to piece together functional classes. While this is certainly open to question (and, in my mind, a pessimistic view of the future), there is no doubting the wisdom in using something that has already been done, whether by the creators of Java, your colleagues or yourself. A good understanding of the class hierarchy will allow you to make the most effective use of pre-written code.
In part one of this series, I introduced the example of a restaurant and the objects found in it: tables, waiters, customers, etc. Many of these objects have similarities between them. Consider that waiters, customers, bartenders, cooks and managers are all people. Despite having additional, unique characteristics associated with job function, they share the attributes and behaviours that define a person. Let’s write a simple Person class that includes a null-argument constructor:
public class Person {
public int age;
public double height;
public String firstName;
public String lastName;
public Person() {
age = 0;
height = 0.0
firstName = new String();
lastName = new String();
}
}
Rather than coding variables for such generic data into the class for each type of employee, we’ve created a base class. All of the employee types will be sub classes that extend Person:
public class Waiter extends Person {
}
Now all of the variables and methods that are found in Person are also in Waiter. The Waiter class can refer to age, height, firstName and lastName, in addition to having its own unique attributes and behaviours.
Person is the base class or super class. Waiter is the derived class or sub class. From within the Waiter class, Person can be referenced using the keyword super. To call the constructor for Person from within Waiter, simply type:
super();
Furthermore, Waiter is a Person. This introduces a concept known as polymorphism, or dynamic binding. The following line of code is perfectly valid, although it will probably strike you as awkward:
Person Robert = new Waiter();
An object can be stored in a variable declared as the type of its super class.
Java doesn’t allow multiple inheritance, which means you can only extend one class. In the case of the above example, it would make sense if that class (Person) was defined as abstract. An abstract class cannot be instantiated; rather it exists only to serve as a base class. Person itself will not actually be used as an object. The objects will be described in more specific classes ( Waiter, Customer, Cook, etc.) that are derived from the abstract class Person.
It should be noted that all objects are ultimately derived from the class Object (part of the Java language). If you do not extend anything in your class declaration, extends Object is implied by default. The Object class forms the base of the class hierarchy. This means that every object has a toString() method, for example (as defined in the Object class).
If anyone actually wants to code a restaurant simulation, here’s a tip: A fun behaviour for a busboy is to smear pizza sauce on the earpiece of the phone, and then use a cell to call the hostess. Too bad I can’t get away with pranks like that at my current job. I guess I was a diabolical slacker all along…
Cooney is a Toronto-based programmer and a freelance Internet developer. He is currently enrolled in Humber College’s Computer Programmer program. He can be reached at robert_cooney@hotmail.com.