Interfaces

Interfaces

The interface keyword takes the abstract concept one step further. You could think of it as a "pure" abstract class. It allows the creator to establish the form for a class: method names, argument lists and return types, but no method bodies. An interface can also contain data members of primitive types, but these are implicitly static and final. An interface provides only a form, but no implementation.

An interface says: "This is what all classes that implement this particular interface will look like." Thus, any code that uses a particular interface knows what methods might be called for that interface, and that's all. So the interface is used to establish a "protocol" between classes. (Some object-oriented programming languages have a keyword called protocol to do the same thing.)

To create an interface, use the interface keyword instead of the class keyword. Like a class, you can add the public keyword before the interface keyword (but only if that interface is defined in a file of the same name) or leave it off to give "friendly" status.

To make a class that conforms to a particular interface (or group of interfaces) use the implements keyword. You're saying "The interface is what it looks like and here's how it works." Other than that, it bears a strong resemblance to inheritance. The diagram for the instrument example shows this:

Once you've implemented an interface, that implementation becomes an ordinary class that can be extended in the regular way.

You can choose to explicitly declare the method declarations in an interface as public. But they are public even if you don't say it. So when you implement an interface, the methods from the interface must be defined as public. Otherwise they would default to "friendly" and you'd be restricting the accessibility of a method during inheritance, which is not allowed by the Java compiler.

You can see this in the modified version of the Instrument example. Note that every method in the interface is strictly a declaration, which is the only thing the compiler allows. In addition, none of the methods in Instrument5 are declared as public, but they're automatically public anyway:

The rest of the code works the same. It doesn't matter if you are upcasting to a "regular" class called Instrument5, an abstract class called Instrument5, or to an interface called Instrument5. The behavior is the same. In fact, you can see in the tune( ) method that there isn't any evidence about whether Instrument5 is a "regular" class, an abstract class or an interface. This is the intent: Each approach gives the programmer different control over the way objects are created and used.