Interfaces as Callbacks

Interfaces can be used to implement callbacks in Java. A callback is a situation where you'd like to pass a reference to some behavior and have another object invoke it later. In C or C++, this is prime territory for function pointers; in Java, we'll use interfaces instead.

Consider two classes: a TickerTape class that displays data and a TextSource class that provides an information feed. We'd like our TextSource to send any new text data. We could have TextSource store a reference to a TickerTape object, but then we could never use our TextSource to send data to any other kind of object. Instead, we'd have to proliferate subclasses of TextSource that dealt with different types. A more elegant solution is to have TextSource store a reference to an interface type, TextUpdateable:

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 ); 
    } 
    ... 
} 

The only thing TextSource really cares about is finding the right method to invoke to send text. Thus, we can list that method in an interface called TextUpdateable and have our TickerTape implement the interface. A TickerTape object can then be used anywhere we need something of the type TextUpdateable. In this case, the TextSource constructor takes a TextUpdateable object and stores the reference in an instance variable of type TextUpdateable. Our TickerTape object simply passes a reference to itself as the callback for text updates, and the source can invoke its receiveText() method as necessary.

Interface Variables

Although interfaces allow us to specify behavior without implementation, there's one exception. An interface can contain constant variable identifiers; these identifiers appear in any class that implements the interface. This functionality allows for predefined parameters that can be used with the methods:

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

The Scaleable interface defines three integers: BIG, MEDIUM, and SMALL. All variables defined in interfaces are implicitly final and static; we don't have to use the modifiers here but, for clarity, we recommend you do so.

A class that implements Scaleable sees these variables:

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

Interfaces and Packages

Interfaces behave like classes within packages. An interface can be declared public to make it visible outside of its package. Under the default visibility, an interface is visible only inside of its package. There can be only one public interface declared in a compilation unit.

Subinterfaces

An interface can extend another interface, just as a class can extend another class. Such an interface is called a subinterface:

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

The interface DynamicallyScaleable extends our previous Scaleable interface and adds an additional method. A class that implements DynamicallyScaleable must implement all methods of both interfaces.

Interfaces can't specify that they implement other interfaces, instead they are allowed to extend more than one interface. (This is multiple inheritence for interfaces). More than one superinterface can be specified with the comma operator:

    interface DynamicallyScaleable extends Scaleable, SomethingElseable {
        ...

Inside Arrays

At the end of Chapter 4, The Java Language, I mentioned that arrays have a place in the Java class hierarchy, but I didn't give you any details. Now that we've discussed the object-oriented aspects of Java, I can give you the whole story.

Array classes live in a parallel Java class hierarchy under the Object class. If a class is a direct subclass of Object, then an array class for that base type also exists as a direct subclass of Object. Arrays of more derived classes are subclasses of the corresponding array classes. For example, consider the following class types:

class Animal { ... } 
class Bird extends Animal { ... } 
class Penguin extends Bird { ... } 

Figure 5.10 illustrates the class hierarchy for arrays of these classes.

Arrays of the same dimension are related to one another in the same manner as their base type classes. In our example, Bird is a subclass of Animal, which means that the Bird[] type is a subtype of Animal[]. In the same way a Bird object can be used in place of an Animal object, a Bird[] array can be assigned to an Animal[] array:

Animal [][] animals; 
Bird [][] birds = new Bird [10][10]; 
birds[0][0] = new Bird(); 
 
// make animals and birds reference the same array object 
animals = birds;   
System.out.println( animals[0][0] );               // prints Bird 

Because arrays are part of the class hierarchy, we can use instanceof to check the type of an array:

if ( birds instanceof Animal[][] )                 // yes 

An array is a subtype of Object and can therefore be assigned to Object type variables:

Object something; 
something = animals; 

Since Java knows the actual type of all objects, you can also cast back if appropriate:

animals = (Animal [][])something; 

Under unusual circumstances, Java may not be able to check the types of objects you place into arrays at compile-time. In those cases, it's possible to receive an ArrayStoreException if you try to assign the wrong type of object to an array element. Consider the following:

class Dog { ... } 
class Poodle extends Dog { ... } 
class Chihuahua extends Dog { ... } 
 
Dog [] dogs; 
Poodle [] poodles = new Poodle [10]; 
 
dogs = poodles;  
 
dogs[3] = new Chihuahua();     // Run-time error, ArrayStoreException 

Both Poodle and Chihuahua are subclasses of Dog, so an array of Poodle objects can therefore be assigned to an array of Dog objects, as I described previously. The problem is that an object assignable to an element of an array of type Dog[] may not be assignable to an element of an array of type Poodle. A Chihuahua object, for instance, can be assigned to a Dog element because it's a subtype of Dog, but not to a Poodle element.[6]

[6] In some sense this could be considered a tiny hole in the Java type system. It doesn't occur elsewhere in Java, only with arrays. This is because array objects exhibit covariance in overriding their assignment and extraction methods. Covariance allows array subclasses to override methods with arguments or return values that are subtypes of the overridden methods, where the methods would normally be overloaded or prohibited. This allows array subclasses to operate on their base types with type safety, but also means that subclasses have different capabilities than their parents, leading to the problem shown above.