5. Objects in Java

5.1 Classes

Classes are the building blocks of a Java application. A class can contain methods, variables, initialization code, and, as we'll discuss later on, even other classes. It serves as a blueprint for making class instances, which are run-time objects that implement the class structure. You declare a class with the class keyword. Methods and variables of the class appear inside the braces of the class declaration:

class Pendulum { 
    float mass;  
    float length = 1.0; 
    int cycles; 
 
    float position ( float time ) { 
        ... 
    } 
    ... 
} 

The above class, Pendulum, contains three variables: mass, length, and cycles. It also defines a method called position() that takes a float value as an argument and returns a float value. Variables and method declarations can appear in any order, but variable initializers can't use forward references to uninitialized variables.

Once we've defined the Pendulum class, we can create a Pendulum object (an instance of that class) as follows:

Pendulum p; 
p = new Pendulum(); 

Recall that our declaration of the variable p does not create a Pendulum object; it simply creates a variable that refers to an object of type Pendulum. We still have to create the object dynamically, using the new keyword. Now that we've created a Pendulum object, we can access its variables and methods, as we've already seen many times:

p.mass = 5.0; 
float pos = p.position( 1.0 ); 

Variables defined in a class are called instance variables. Every object has its own set of instance variables; the values of these variables in one object can differ from the values in another object, as shown in Figure 5.1. If you don't initialize an instance variable when you declare it, it's given a default value appropriate for its type.

In Figure 5.1, we have a hypothetical TextBook application that uses two instances of Pendulum through the reference type variables bigPendulum and smallPendulum. Each of these Pendulum objects has its own copy of mass, length, and cycles.

As with variables, methods defined in a class are instance methods. An instance method is associated with an instance of the class, but each instance doesn't really have its own copy of the method. Instead, there's just one copy of the method, but it operates on the values of the instance variables of a particular object. As you'll see later when we talk about subclassing, there's more to learn about method selection.

class Pendulum { 
    ... 
    void resetEverything() { 
        cycles = 0; 
        mass = 1.0; 
        ... 
        float startingPosition = position( 0.0 ); 
    } 
    ... 
} 

class TextBook { 
    ... 
    void showPendulum() { 
        Pendulum bob = new Pendulum(); 
        ... 
        int i = bob.cycles; 
        bob.resetEverything(); 
        bob.mass = 1.01; 
        ... 
    } 
    ... 
} 

class Pendulum { 
    ... 
    private int cycles; 
    ... 

class TextBook { 
    ... 
    void showPendulum() { 
        ... 
        int i = bob.cycles;         // Compile time error 

class Pendulum { 
    ... 
    static float gravAccel = 9.80; 
    ... 

class Pendulum { 
    ... 
    float getWeight () { 
        return mass * gravAccel; 
    } 
    ... 
} 

Pendulum.gravAccel = 8.76; 

class Pendulum { 
    ... 
    static final float EARTH_G = 9.80; 
    ... 

class Pendulum { 
    ... 
    static int SIMPLE = 0, ONE_SPRING = 1, TWO_SPRING = 2; 
    ... 

Pendulum pendy = new Pendulum(); 
pendy.setType( Pendulum.ONE_SPRING ); 

class Pendulum { 
    ... 
    void resetEverything() { 
        setType ( SIMPLE ); 
        ... 
    } 
    ... 
} 

5.2 Methods

Methods appear inside class bodies. They contain local variable declarations and other Java statements that are executed by a calling thread when the method is invoked. Method declarations in Java look like ANSI C-style function declarations with two restrictions:

• A method in Java always specifies a return type (there's no default). The returned value can be a primitive numeric type, a reference type, or the type void, which indicates no returned value.
• A method always has a fixed number of arguments. The combination of method overloading and true arrays removes most of the need for a variable number of arguments. These techniques are type-safe and easier to use than C's variable argument list mechanism.

Here's a simple example:

class Bird { 
    int xPos, yPos; 
 
    double fly ( int x, int y ) { 
        double distance = Math.sqrt( x*x + y*y ); 
        flap( distance ); 
        xPos = x; 
        yPos = y; 
        return distance; 
    } 
    ... 
} 

In this example, the class Bird defines a method, fly(), that takes as arguments two integers: x and y. It returns a double type value as a result.

class Bird { 
    int xPos, yPos; 
    int xNest, yNest; 
    ... 
    double flyToNest() { 
        int xPos = xNest; 
        int yPos = yNest: 
        return ( fly( xPos, yPos ) ); 
    } 
    ... 
} 

class Bird { 
    int xPos, yPos; 
 
    double fly ( int xPos, int yPos ) { 
        double distance = Math.sqrt( xPos*xPos + yPos*yPos ); 
        flap( distance ); 
        this.xPos = xPos; 
        this.yPos = yPos; 
        return distance; 
    } 
    ... 
} 

class Bird { 
    ... 
    static String [] getBirdTypes( ) { 
    String [] types; 
    // Create list...
        return types; 
    } 
    ... 
} 

String [] names = Bird.getBirdTypes(); 

void myMethod() { 
    int foo = 42; 
    int bar; 
 
    // bar += 1;       // Compile time error, bar uninitialized
 
    bar = 99; 
    bar += 1;       // ok here
} 

void myMethod { 
    int foo; 
 
    if ( someCondition ) { 
        foo = 42; 
        ... 
    } 
 
    foo += 1;                  // Compile time error 
                               // foo may not have been initialized 

int foo; 
... 
if ( someCondition ) { 
    foo = 42; 
    ... 
} else 
    return;   
 
foo += 1; 

Argument Passing and References

Let's consider what happens when you pass arguments to a method. All primitive data types (e.g., int, char, float) are passed by value. Now you're probably used to the idea that reference types (i.e., any kind of object, including arrays and strings) are used through references. An important distinction (that we discussed briefly in Chapter 4) is that the references themselves (the pointers to these objects) are actually primitive types, and are passed by value too.

Consider the following piece of code:

// somewhere
    int i = 0; 
    SomeKindOfObject obj = new SomeKindOfObject(); 
    myMethod( i, obj ); 
    ... 
void myMethod(int j, SomeKindOfObject o) { 
    ... 
} 

The first chunk of code calls myMethod(), passing it two arguments. The first argument, i, is passed by value; when the method is called, the value of i is copied into the method's parameter j. If myMethod() changes the value of i, it's changing only its copy of the local variable.

In the same way, a copy of the reference to obj is placed into the reference variable o of myMethod(). Both references refer to the same object, of course, and any changes made through either reference affect the actual (single) object instance, but there are two copies of the pointer. If we change the value of, say, o.size, the change is visible through either reference. However, if myMethod() changes the reference o itself--to point to another object--it's affecting only its copy. In this sense, passing the reference is like passing a pointer in C and unlike passing by reference in C++.

What if myMethod() needs to modify the calling method's notion of the obj reference as well (i.e., make obj point to a different object)? The easy way to do that is to wrap obj inside some kind of object. A good candidate would be to wrap the object up as the lone element in an array:

SomeKindOfObject [] wrapper = { obj };

All parties could then refer to the object as wrapper[0] and would have the ability to change the reference. This is not very asthetically pleasing, but it does illustrate that what is needed is the level of indirection. Another possibility is to use this to pass a reference to the calling object.

Let's look at another piece of code that could be from an implementation of a linked list:

class Element { 
    public Element nextElement; 
 
    void addToList( List list ) { 
        list.addToList( this ); 
    } 
} 
 
class List { 
    void addToList( Element element ) { 
        ... 
        element.nextElement = getNextElement(); 
    } 
} 

Every element in a linked list contains a pointer to the next element in the list. In this code, the Element class represents one element; it includes a method for adding itself to the list. The List class itself contains a method for adding an arbitrary Element to the list. The method addToList() calls addToList() with the argument this (which is, of course, an Element). addToList() can use the this reference to modify the Element's nextElement instance variable. The same technique can be used in conjunction with interfaces to implement callbacks for arbitrary method invocations.

Method Overloading

Method overloading is the ability to define multiple methods with the same name in a class; when the method is invoked, the compiler picks the correct one based on the arguments passed to the method. This implies, of course, that overloaded methods must have different numbers or types of arguments. In a later section we'll look at method overriding, which occurs when we declare methods with identical signatures in different classes.

Method overloading is a powerful and useful feature. It's another form of polymorphism (ad-hoc polymorphism). The idea is to create methods that act in the same way on different types of arguments and have what appears to be a single method that operates on any of the types. The Java PrintStream's print() method is a good example of method overloading in action. As you've probably deduced by now, you can print a string representation of just about anything using the expression:

System.out.print( argument ) 

The variable out is a reference to an object (a PrintStream) that defines nine different versions of the print() method. They take, respectively, arguments of the following types: Object, String, char[], char, int, long, float, double, and boolean.

class PrintStream { 
    void print( Object arg ) { ... } 
    void print( String arg ) { ... } 
    void print( char [] arg ) { ... } 
    ... 
} 

You can invoke the print() method with any of these types as an argument, and it's printed in an appropriate way. In a language without method overloading, this would require something more cumbersome, such as a separate method for printing each type of object. Then it would be your responsibility to remember what method to use for each data type.

In the above example, print() has been overloaded to support two reference types: Object and String. What if we try to call print() with some other reference type? Say, perhaps, a Date object? The answer is that since Date is a subclass of Object, the Object method is selected. When there's not an exact type match, the compiler searches for an acceptable, assignable match. Since Date, like all classes, is a subclass of Object, a Date object can be assigned to a variable of type Object. It's therefore an acceptable match, and the Object method is selected.

But what if there's more than one possible match? Say, for example, we tried to print a subclass of String called MyString. (Of course, the String class is final, so it can't be subclassed, but allow me this brief transgression for purposes of explanation.) MyString is assignable to either String or to Object. Here the compiler makes a determination as to which match is "better" and selects that method. In this case it's the String method.

The intuitive explanation is that the String class is closer to MyString in the inheritance hierarchy. It is a more specific match. A more rigorous way of specifying it would be to say that a given method is more specific than another method with respect to some arguments it wants to accept if the argument types of the first method are all assignable to the argument types of the second method. In this case, the String method is more specific to a subclass of String than the Object method because type String is assignable to type Object. The reverse is obviously not true.

If you're paying close attention, you may have noticed I said that the compiler resolves overloaded methods. Method overloading is not something that happens at run-time; this is an important distinction. It means that the selected method is chosen once, when the code is compiled. Once the overloaded method is selected, the choice is fixed until the code is recompiled, even if the class containing the called method is later revised and an even more specific overloaded method is added. This is in contrast to overridden (virtual) methods, which are located at run-time and can be found even if they didn't exist when the calling class was compiled. We'll talk about method overriding later in the chapter.

One last note about overloading. In earlier chapters, we've pointed out that Java doesn't support programmer-defined overloaded operators, and that + is the only system-defined overloaded operator. If you've been wondering what an overloaded operator is, I can finally clear up that mystery. In a language like C++, you can customize operators such as + and * to work with objects that you create. For example, you could create a class Complex that implements complex numbers, and then overload methods corresponding to + and * to add and multiply Complex objects. Some people argue that operator overloading makes for elegant and readable programs, while others say it's just "syntactic sugar" that makes for obfuscated code. The Java designers clearly espoused the later opinion when they chose not to support programmer-defined overloaded operators.

5.3 Object Creation

Objects in Java are allocated from a system heap space, much like malloc'ed storage in C or C++. Unlike C or C++, however, we needn't manage that memory ourselves. Java takes care of memory allocation and deallocation for you. Java explicitly allocates storage for an object when you create it with the new keyword. More importantly, objects are removed by garbage collection when they're no longer referenced.

class Date { 
    long time; 
 
    Date() { 
        time = currentTime(); 
    } 
 
    Date( String date ) { 
        time = parseDate( date ); 
    } 
    ... 
} 

Date now = new Date(); 
Date christmas = new Date("Dec 25, 1997"); 

christmas = null;          // fair game for the garbage collector 

class Car { 
    String model; 
    int doors; 
 
    Car( String m, int d ) { 
        model = m; 
        doors = d; 
        // other, complicated setup 
        ... 
    } 
 
    Car( String m ) { 
        this( m, 4 ); 
    } 
    ... 
} 

Car( String m ) { 
    int doors = determineDoors(); 
    this( m, doors );   // Error  
}                       // Constructor call must be first statement 

class Car {  
    ... 
    final int default_doors = 4; 
    ... 
 
    Car( String m ) { 
        this( m, default_doors ); // Error 
                                  // Referencing uninitialized variable 
    } 
    ... 
} 

class Car { 
    ... 
    static final int DEFAULT_DOORS = 4; 
    ... 
 
    Car( String m ) { 
        this( m, DEFAULT_DOORS );  // Okay now 
    } 
    ... 
} 

class MyClass {
    Properties myProps = new Properties();
    // set up myProps
    {
        myProps.put("foo", "bar);
        myProps.put("boo", "gee);
    }
    int a = 5;
    ...

class ColorWheel { 
    static Hashtable colors = new Hashtable(); 
 
    // set up colors
    static { 
        colors.put("Red", Color.red ); 
        colors.put("Green", Color.green ); 
        colors.put("Blue", Color.blue ); 
        ... 
    } 
    ... 
} 

5.4 Object Destruction

Now that we've seen how to create objects, it's time to talk about their destruction. If you're accustomed to programming in C or C++, you've probably spent time hunting down memory leaks in your code. Java takes care of object destruction for you; you don't have to worry about memory leaks, and you can concentrate on more important programming tasks.

5.5 Subclassing and Inheritance

Classes in Java exist in a class hierarchy. A class in Java can be declared as a subclass of another class using the extends keyword. A subclass inherits variables and methods from its superclass and uses them as if they're declared within the subclass itself:

class Animal { 
    float weight; 
    ... 
    void eat() { 
        ... 
    } 
    ... 
} 
 
class Mammal extends Animal { 
    int heartRate; 
    // inherits weight 
    ... 
    void breathe() { 
        ... 
    } 
    // inherits eat() 
} 

In the above example, an object of type Mammal has both the instance variable weight and the method eat(). They are inherited from Animal.

A class can extend only one other class. To use the proper terminology, Java allows single inheritance of class implementation. Later we'll talk about interfaces, which take the place of multiple inheritance as it's primarily used in C++.

A subclass can, of course, be further subclassed. Normally, subclassing specializes or refines a class by adding variables and methods:

class Cat extends Mammal { 
    boolean longHair; 
    // inherits weight and heartRate 
    ... 
    void purr() { 
        ... 
    } 
    // inherits eat() and breathe()  
} 

The Cat class is a type of Mammal that is ultimately a type of Animal. Cat objects inherit all the characteristics of Mammal objects and, in turn, Animal objects. Cat also provides additional behavior in the form of the purr() method and the longHair variable. We can denote the class relationship in a diagram, as shown in Figure 5.3.

A subclass inherits all members of its superclass not designated as private. As we'll discuss shortly, other levels of visibility affect what inherited members of the class can be seen from outside of the class and its subclasses, but at a minimum, a subclass always has the same set of visible members as its parent. For this reason, the type of a subclass can be considered a subtype of its parent, and instances of the subtype can be used anywhere instances of the supertype are allowed. For example:

Cat simon = new Cat(); 
Animal creature = simon; 

The Cat simon in the above example can be assigned to the Animal type variable creature because Cat is a subtype of Animal.

class IntegerCalculator { 
    int sum; 
    ... 
} 
 
class DecimalCalculator extends IntegerCalculator { 
    double sum; 
    ... 
} 

Since both variables exist in DecimalCalculator, we need to reference the variable inherited from IntegerCalculator. We do that using the super reference:

int s = super.sum 

Inside of DecimalCalculator, the super keyword used in this manner refers to the sum variable defined in the superclass. I'll explain the use of super more fully in a bit.

Another important point about shadowed variables has to do with how they work when we refer to an object by way of a less derived type. For example, we can refer to a DecimalCalculator object as an IntegerCalculator. If we do so and then access the variable sum, we get the integer variable, not the decimal one:

DecimalCalculator dc = new DecimalCalculator(); 
IntegerCalculator ic = dc; 
 
int s = ic.sum;                  // Accesses IntegerCalculator sum 

After this detailed explanation, you may still be wondering what shadowed variables are good for. Well, to be honest, the usefulness of shadowed variables is limited, but it's important to understand the concepts before we talk about doing the same thing with methods. We'll see a different and more dynamic type of behavior with method shadowing, or more correctly, method overriding.

Overriding Methods

In a previous section, we saw we could declare overloaded methods (i.e., methods with the same name but a different number or type of arguments) within a class. Overloaded method selection works the way I described on all methods available to a class, including inherited ones. This means that a subclass can define some overloaded methods that augment the overloaded methods provided by a superclass.

But a subclass does more than that; it can define a method that has exactly the same method signature (arguments and return type) as a method in its superclass. In that case, the method in the subclass overrides the method in the superclass and effectively replaces its implementation, as shown in Figure 5.5. Overriding methods to change the behavior of objects is another form of polymorphism (sub-type polymorphism): the one most people think of when they talk about the power of object-oriented languages.

In Figure 5.5, Mammal overrides the reproduce() method of Animal, perhaps to specialize the method for the peculiar behavior of Mammals giving live birth.[4] The Cat object's sleeping behavior is overridden to be different from that of a general Animal, perhaps to accommodate cat naps. The Cat class also adds the more unique behaviors of purring and hunting mice.

[4] We'll ignore the platypus, which is an obscure nonovoviviparous mammal.

Overridden methods and dynamic binding

In a previous section, I mentioned that overloaded methods are selected by the compiler at compile-time. Overridden methods, on the other hand, are selected dynamically at run-time. Even if we create an instance of a subclass our code has never seen before (perhaps a new object type loaded from the network), any overridden methods that it contains will be located and invoked at run-time to replace those that existed when we last compiled our code.

In contrast, if we load a new class that implements an additional, more specific overloaded method, our code will continue to use the implementation it discovered at compile-time. Another effect of this is that casting (i.e., explicitly telling the compiler to treat an object as one of its assignable types) affects the selection of overloaded methods, but not overridden methods.

Static method binding

Static methods do not belong to any object instance, they are accessed directly through a class name, so they are not dynamically selected at run-time like instance methods. That is why static methods are called "static"--they are always bound at compile time.

A static method in a superclass can be shadowed by another static method in a subclass, as long as the original method was not declared final. However, you can't override a static method with a nonstatic method. In other words, you can't change a static method into an instance method in a subclass.

Dynamic method selection and peformance

When Java has to dynamically search for overridden methods in subclasses, there's a small performance penalty. In languages like C++, the default is for methods to act like shadowed variables, so you have to explicitly declare the methods you want to be virtual. Java is more dynamic, and the default is for all instance methods to be virtual. In Java you can, however, go the other direction and explicitly declare that an instance method can't be overridden, so that it will not be subject to dynamic binding and will not suffer in terms of performance. This is done with the final modifier. We have seen final used with variables to effectively make them constants. When final is applied to a method, it means that that method can't be overridden (in some sense, its implementation is constant). final can also be applied to an entire class, which means the class can't be subclassed.

Compiler optimiziations

When javac, the Java compiler, is run with the -O switch, it performs certain optimizations. It can inline final methods to improve performance (while slightly increasing the size of the resulting class file). private methods, which are effectively final, can also be inlined, and final classes may also benefit from more powerful optimizations.

Another kind of optimization allows you to include debugging code in your Java source without penalty. Java doesn't have a pre-processor, to explicitly control what source is included, but you can get some of the same effects by making a block of code conditional on a constant (i.e., static and final) variable. The Java compiler is smart enough to remove this code when it determines that it won't be called. For example:

static final boolean DEBUG = false;
...
static void debug (String message) { 
    if (DEBUG) {
        System.err.println(message); 
        // do other stuff
        ...
    }
}

If we compile the above code using the -O switch, the compiler will recognize that the condition on the DEBUG variable is always false, and the body of the debug() method will be optimized away. But that's not all--since debug() itself is also final it can be inlined, and an empty inlined method generates no code at all. So, when we compile with DEBUG set to false, calls to the debug() method will generate no residual code at all.

Method selection revisited

By now you should have a good, intuitive idea as to how methods are selected from the pool of potentially overloaded and overridden method names of a class. If, however, you are dying for a dry definition, I'll provide one now. If you are satisfied with your understanding, you may wish to skip this little exercise in logic.

In a previous section, I offered an inductive rule for overloaded method resolution. It said that a method is considered more specific than another if its arguments are polymorphically assignable to the arguments of the second method. We can now expand this rule to include the resolution of overridden methods by adding the following condition: to be more specific than another method, the type of the class containing the method must also be assignable to the type of the class holding the second method.

What does that mean? Well, the only classes whose types are assignable are classes in the same inheritance hierarchy. So, what we're talking about now is the set of all methods of the same name in a class or any of its parent or child classes. Since subclass types are assignable to superclass types, but not vice versa, the resolution is pushed, in the way that we expect, down the chain, towards the subclasses. This effectively adds a second dimension to the search, in which resolution is pushed down the inheritance tree towards more refined classes and, simultaneously, towards the most specific overloaded method within a given class.

Exceptions and overridden methods

When we talked about exception handling in Chapter 4, The Java Language, there's one thing I didn't mention because it wouldn't have made sense then. An important restriction on overridden methods is that they must adhere to the throws clause of the parent method's signature. If an overridden method throws an exception, the exception must be of the type specified by the parent or a subtype of that exception. Because the exception can be a subtype of the one specified by the parent, the overridden method can refine the type of exception thrown to go along with its new behavior. For example:

// A more refined exception 
class MeatInedibleException extends InedibleException { ...
}
        
class Animal {
    void eat( Food f ) throws InedibleException { ...
}
class Herbivore extends Animal {
    void eat( Food f ) throws InedibleException { 
        if ( f instanceof Meat )
            throw new MeatInedibleException();
        ....
    }
}

In the example above, Animal specifies that it can throw an InedibleException from its eat() method. Herbivore is a subclass Animal, so it must be able to do this too. However, Herbivore's eat() method actually throws a more specific exception: MeatInedibleException. It can do this because MeatInedibleException is a subtype of InedibleException (remember that Exceptions are classes too). Our calling code's catch clause can therefore be more specific:

Animal creature = ...
try {
    creature.eat( food );
} catch ( MeatInedibleException ) {
    // creature can't eat this food because it's meat
} catch ( InedibleException ) {
    // creature can't eat this food
}

this and super

The special references this and super allow you to refer to the members of the current object instance or those of the superclass, respectively. We have seen this used elsewhere to pass a reference to the current object and to refer to shadowed instance variables. The reference super does the same for the parents of a class. You can use it to refer to members of a superclass that have been shadowed or overridden. A common arrangement is for an overridden method in a subclass to do some preliminary work and then defer to the method of the superclass to finish the job.

class Animal { 
    void eat( Food f ) throws InedibleException { 
        // consume food
    }
} 
 
class Herbivore extends Animal { 
    void eat( Food f ) throws InedibleException { 
        // check if edible
        ...
        super.eat( f ); 
    } 
} 

In the above example, our Herbivore class overrides the Animal eat() method to first do some checking on the food object. After doing its job it simply calls the (otherwise overridden) implementation of eat() in its superclass, using super.

super prompts a search for the method or variable to begin in the scope of the immediate superclass rather than the current class. The inherited method or variable found may reside in the immediate superclass, or in a more distant one. The usage of the super reference when applied to overridden methods of a superclass is special; it tells the method resolution system to stop the dynamic method search at the superclass, instead of in the most derived class (as it otherwise does). Without super, there would be no way to access overridden methods.

Casting

As in C++, a cast explicitly tells the compiler to change the apparent type of an object reference. Unlike in C++, casts in Java are checked both at compile- and at run-time to make sure they are legal. Attempting to cast an object to an incompatible type at run-time results in a ClassCastException. Only casts between objects in the same inheritance hierarchy (and as we'll see later, to appropriate interfaces) are legal in Java and pass the scrutiny of the compiler and the run-time system.

Casts in Java affect only the treatment of references; they never change the form of the actual object. This is an important rule to keep in mind. You never change the object pointed to by a reference by casting it; you change only the compiler's (or run-time system's) notion of it.

A cast can be used to narrow the type of a reference--to make it more specific. Often, we'll do this when we have to retrieve an object from a more general type of collection or when it has been previously used as a less derived type. (The prototypical example is using an object in a Vector or Hashtable, as you'll see in Chapter 7, Basic Utility Classes.) Continuing with our Cat example:

Animal creature = ...
Cat simon = ...
 
creature = simon;        // Okay
// simon = creature;     // Compile time error, incompatible type 
simon = (Cat)creature;   // Okay 

We can't reassign the reference in creature to the variable simon even though we know it holds an instance of a Cat (Simon). We have to perform the indicated cast. This is also called downcasting the reference.

Note that an implicit cast was performed when we went the other way to widen the reference simon to type Animal during the first assignment. In this case, an explicit cast would have been legal, but superfluous.

If casting seems complicated, here's a simple way to think about it. Basically, you can't lie about what an object is. If you have a Cat object, you can cast it to a less derived type (i.e., a type above it in the class hierarchy) such as Animal or even Object, since all Java classes are a subclass of Object. If you have an Object you know is a Cat, you can downcast the Object to be an Animal or a Cat. However, if you aren't sure if the Object is a Cat or a Dog at run-time, you should check it with instanceof before you perform the cast. If you get the cast wrong, Java throws a ClassCastException.

As I mentioned earlier, casting can affect the selection of compile-time items like variables and overloaded methods, but not the selection of overridden methods. Figure 5.6 shows the difference. As shown in the top half of the diagram, casting the reference simon to type Animal (widening it) affects the selection of the shadowed variable weight within it. However, as the lower half of the diagram indicates, the cast doesn't affect the selection of the overridden method sleep().

Using superclass constructors

When we talked earlier about constructors, we discussed how the special statement this() invokes an overloaded constructor upon entry to another constructor. Similarly, the statement super() explicitly invokes the constructor of a superclass. Of course, we also talked about how Java makes a chain of constructor calls that includes the superclass's constructor, so why use super() explicitly? When Java makes an implicit call to the superclass constructor, it calls the default constructor. So, if we want to invoke a superclass constructor that takes arguments, we have to do so explicitly using super().

If we are going to call a superclass constructor with super(), it must be the first statement of our constructor, just as this() must be the first call we make in an overloaded constructor. Here's a simple example:

class Person { 
    Person ( String name ) { 
        //  setup based on name 
        ... 
    } 
    ... 
} 
 
class Doctor extends Person { 
    Doctor ( String name, String specialty ) { 
        super( name ); 
        // setup based on specialty 
        ... 
    } 
    ... 
} 

In this example, we use super() to take advantage of the implementation of the superclass constructor and avoid duplicating the code to set up the object based on its name. In fact, because the class Person doesn't define a default (no arguments) constructor, we have no choice but to call super() explicitly. Otherwise, the compiler would complain that it couldn't find an appropriate default constructor to call. Said another way, if you subclass a class that has only constructors that take arguments, you have to invoke one of the superclass's constructors explicitly from your subclass constructor.

Instance variables of the class are initialized upon return from the superclass constructor, whether that's due to an explicit call via super() or an implicit call to the default superclass constructor.

We can now give the full story of how constructors are chained together and when instance variable initialization occurs. The rule has three parts and is applied repeatedly for each successive constructor invoked.

• If the first statement of a constructor is an ordinary statement--i.e., not a call to this() or super()--Java inserts an implicit call to super() to invoke the default constructor of the superclass. Upon returning from that call, Java initializes the instance variables of the current class and proceeds to execute the statements of the current constructor.
• If the first statement of a constructor is a call to a superclass constructor via super(), Java invokes the selected superclass constructor. Upon its return, Java initializes the current class's instance variables and proceeds with the statements of the current constructor.
• If the first statement of a constructor is a call to an overloaded constructor via this(), Java invokes the selected constructor and upon its return simply proceeds with the statements of the current constructor. The call to the superclass's constructor has happened within the overloaded constructor, either explicitly or implicitly, so the initialization of instance variables has already occurred.

Abstract Methods and Classes

As in C++, a method can be declared with the abstract modifier to indicate that it's just a prototype. An abstract method has no body; it's simply a signature definition followed by a semicolon. You can't directly use a class that contains an abstract method; you must instead create a subclass that implements the abstract method's body.

abstract vaporMethod( String name ); 

In Java, a class that contains one or more abstract methods must be explicitly declared as an abstract class, also using the abstract modifier :

abstract class vaporClass { 
    ... 
    abstract vaporMethod( String name ); 
    ... 
} 

An abstract class can contain other, nonabstract methods and ordinary variable declarations; however, it can't be instantiated. To be used, it must be subclassed and its abstract methods must be overridden with methods that implement a body. Not all abstract methods have to be implemented in a single subclass, but a subclass that doesn't override all its superclass's abstract methods with actual, concrete implementations must also be declared abstract.

Abstract classes provide a framework for classes that are to be "filled in" by the implementor. The java.io.InputStream class, for example, has a single abstract method called read(). Various subclasses of InputStream implement read() in their own ways to read from their own sources. The rest of the InputStream class, however, provides extended functionality built on the simple read() method. A subclass of InputStream inherits these nonabstract methods that provide functionality based on the simple read() method that the subclass implements.

It's often desirable to specify only the prototypes for a whole set of methods and provide no implementation. In C++, this would be a purely abstract class. In Java, you should instead use an interface. An interface is like a purely abstract class; it defines a set of methods a class must implement (i.e., the behavior of a class). However, unlike in C++, a class in Java can simply say that it implements an interface and go about implementing those methods. As we'll discuss later, a class that implements an interface doesn't have to inherit from any particular part of the inheritance hierarchy or use a particular implementation.

5.6 Packages and Compilation Units

A package is a name for a group of related classes. In Chapter 3, Tools of the Trade, we discussed how Java uses package names to locate classes during compilation and at run-time. In this sense, packages are somewhat like libraries; they organize and manage sets of classes. Packages provide more than just source code-level organization though. They also create an additional level of scope for their classes and the variables and methods within them. We'll talk about the visibility of classes in this section. In the next section, we'll discuss the effect that packages have on access to variables and methods between classes.

package mytools.text; 
 
class TextComponent { 
     ... 
} 

package mytools.text; 
 
public class TextEditor { 
     ... 
} 

package somewhere.else; 
 
import mytools.text.TextEditor; 
 
class MyClass { 
    TextEditor editBoy; 
    ... 
} 

import mytools.text.*; 

5.7 Variable and Method Visibility

One of the most important aspects of object-oriented design is data hiding, or encapsulation. By treating an object in some respects as a "black box" and ignoring the details of its implementation, we can write stronger, simpler code with components that can be easily reused.

Subclasses and Visibility

There are two important (but unrelated) notes we need to add to the discussion of visibility with regards to class members in subclasses. First, when you override methods of a class in a subclass, it's not possible to reduce their visibility. While it is possible to take a private method of a class and override it to be public in a subclass, the reverse is not possible. This makes sense when you think about the fact that subtypes have to be usable as instances of their supertype (e.g., a Mammal is a type of Animal). If we could reduce the visibility of an overridden method, this would be a problem. However, we can reduce the visibility of a variable because it simply results in a shadowed variable. As with all shadowed variables, the two variables are distinct and can have separate visibilities in their different class forms.

The second point is that protected variables of a class are visible to its subclasses, but unlike C++, only in objects of the subclass's type or its subtypes. In other words, a subclass can see a protected variable from its superclass as an inherited variable, but it can't access the variable in a separate instance of the superclass itself. This can be confusing because often we forget that visibility modifiers don't resrtict between multiple instances of the same class in the same way that they do instances of different classes. Two instances of the same type of object can normally access all of each other's members, including private ones. Said another way: two instances of Cat can access all of each other's variables and methods (including private ones), but a Cat can't access a protected member in an instance of Animal, unless it can prove that the Animal is a Cat.

5.8 Interfaces

Interfaces are kind of like Boy Scout (or Girl Scout) merit badges. When a scout has learned to build a bird house, he can walk around wearing a little patch with a picture of one on his sleeve. This says to the world, "I know how to build a bird house." Similarly, an interface is a list of methods that define some set of behavior for an object. Any class that implements each of the methods listed in the interface can declare that it implements the interface and wear, as its merit badge, an extra type--the interface's type.

Interface types act like class types. You can declare variables to be of an interface type, you can declare arguments of methods to accept interface types, and you can even specify that the return type of a method is an interface type. In each of these cases, what is meant is that any object that implements the interface (i.e., wears the right merit badge) can fill that spot. In this sense, interfaces are orthogonal to the class hierarchy. They cut across the boundaries of what kind of object an item is and deal with it only in terms of what it can do. A class implements as many interfaces as it desires. In this way, interfaces in Java replace the need for multiple inheritance (and all of its messy side effects).

An interface looks like a purely abstract class (i.e., a class with only abstract methods). You define an interface with the interface keyword and list its methods with no bodies:

interface Driveable { 
    boolean startEngine(); 
    void stopEngine(); 
    float accelerate( float acc ); 
    boolean turn( Direction dir ); 
} 

The example above defines an interface called Driveable with four methods. It's acceptable, but not necessary, to declare the methods in an interface with the abstract modifier, so we haven't used it here. Interfaces define capabilities, so it's common to name interfaces after their capabilities in a passive sense. "Driveable" is a good example; "runnable" and "updateable" would be two more.

Any class that implements all the methods can then declare it implements the interface by using a special implements clause in its class definition:

class Automobile implements Driveable { 
    ... 
    boolean startEngine() { 
        if ( notTooCold ) 
            engineRunning = true; 
        ... 
    } 
 
    void stopEngine() { 
        engineRunning = false; 
    } 
 
    float accelerate( float acc ) { 
        ... 
    } 
 
    boolean turn( Direction dir ) { 
        ... 
    } 
    ... 
} 

The class Automobile implements the methods of the Driveable interface and declares itself Driveable using an implements clause.

As shown in Figure 5.9, another class, such as LawnMower, can also implement the Driveable interface. The figure illustrates the Driveable interface being implemented by two different classes. While it's possible that both Automobile and Lawnmower could derive from some primitive kind of vehicle, they don't have to in this scenario. This is a significant advantage of interfaces over standard multiple inheritance as implemented in C++.

After declaring the interface, we have a new type, Driveable. We can declare variables of type Driveable and assign them any instance of a Driveable object:

Automobile auto = new Automobile(); 
Lawnmower mower = new Lawnmower(); 
Driveable vehicle; 
 
vehicle = auto; 
vehicle.startEngine(); 
vehicle.stopEngine(); 
... 
vehicle = mower; 
vehicle.startEngine(); 
vehicle.stopEngine(); 

Both Automobile and Lawnmower implement Driveable and can be considered of that type.

interface TextUpdateable { 
    receiveText( String text ); 
} 
 
class TickerTape implements TextUpdateable { 
    TextSource source; 
 
    init() { 
        source = new TextSource( this ); 
        ... 
    } 
 
    public receiveText( String text ) { 
        scrollText( text ): 
    } 
    ... 
} 
 
class TextSource { 
    TextUpdateable receiver; 
 
    TextSource( TextUpdateable r ) { 
        receiver = r; 
    } 
 
    private sendText( String s ) { 
        receiver.receiveText( s ); 
    } 
    ... 
} 

interface Scaleable { 
    static final int BIG = 0, MEDIUM = 1, SMALL = 2; 
 
    void setScale( int size ); 
} 

class Box implements Scaleable { 
 
    void setScale( int size ) { 
        switch( size ) { 
            case BIG: 
                ... 
            case MEDIUM: 
                ... 
            case SMALL: 
                ... 
        } 
    } 
    ... 
} 

interface DynamicallyScaleable extends Scaleable { 
    void changeScale( int size ); 
} 

    interface DynamicallyScaleable extends Scaleable, SomethingElseable {
        ...