Interfaces

An interface is a very similar to a class, except that (a) it contains no fields, and (b) its methods have no bodies. In other words, it specifies how a class behaves (what methods it provides) without commenting on how the class is implemented. An example of an interface, to represent a domino, is given in Figure 2-23. (We didn't need to represent dominoes in this much detail in Domineering, but this might be useful in other games.)

Figure 2-23. In an interface, there are no fields or method bodies.

A class which provides methods with these signatures can be said to implement the interface. The FieldDomino class (Figure 2-24) implements the Domino interface. Beware of the potential confusion between this Java-specific meaning of the word "implement" and its more general meaning of "provide code for," as in, "Implement this algorithm."

It is okay to leave off comments for the methods specified in the interfacejavadoc is smart enough to copy them from the interface. Indeed, putting the comment in only one place (the interface) reduces the chance that inconsistent comments will appear.

It is possible for more than one class to implement the same interface. The ArrayDomino class (Figure 2-25) represents a domino in a different way. It is also possible for a class to implement

Figure 2-24. The FieldDomino class uses two fields to hold the left and right numbers on the domino.

more than one interface, as long as it provides all of the methods specified by each of those interfaces.

Domino is a polymorphic type, which can hold a reference to an instance of any class which implements the Domino interface. Thus, if we declare a variable

Domino bone;

we can say either

bone = new FieldDomino(2, 3);

Figure 2-25. The ArrayDomino class uses an array of two ints instead of two int fields.

or:

bone = new ArrayDomino(2, 3);

The relationship between the Domino interface and the FieldDomino and ArrayDomino classes is shown in Figure 2-26. It is not necessary to list the interface methods in the boxes for the classes.

Figure 2-26. UML class diagram showing the relationship between the Domino interface and the FieldDomino and ArrayDomino classes. The dashed, hollow-headed arrows say that both classes implement the interface. The methods in the Domino interface are in italic to emphasize that they are only required, not provided, by the interface.

(This item is displayed on page 58 in the print version)

An interface used to specify all of the important methods of any implementing class is sometimes called an abstract data type or ADT. If you are going to write a class involving variables of type Domino and I am going to write an implementation of the Domino interface, we can start by writing the ADT. As long as I provide the required methods and you do not expect any others, our classes will work together perfectly when they are done.

Many software engineers argue that a class implementing an abstract data type should provide only the methods required by the interface. (There are a few exceptions: constructors, nonpublic methods, common methods like toString(), and main() methods for testing.) If an implementation provides some other public method (say, isDoublet() to determine if both numbers on a Domino are the same), any code which takes advantage of this method will break if we switch to a different implementation which does not provide it.

There are other uses for interfaces besides specifying abstract data types. For example, the Comparable interface (Chapter 8) is used to specify that an object can be compared to other instances of its class. Since Comparable is a polymorphic type, it is possible to write one sorting method which works on any array of Comparables. The interface requires only one method, compareTo(), but nobody would expect a class to have only this method. Classes such as Integer and String are designed for other purposes and also implement Comparable.

Exercises