Interfaces

You can already make one variable stand in for many kinds of object, and you can make a parent class force its children to write certain methods. The next step is to describe an ability on its own, apart from any family of classes: whatever this thing is, it can be drawn. A promise like that is called an interface. Java's own library is full of them, and by the end of this lesson you will be writing your own.

A capability that crosses family lines#

Suppose you are building a small drawing program. It paints shapes on a screen, but it also paints other things: a button, a chart, a line of text. What all of these share is that the program can ask each one to draw itself. They share a capability, drawing, but not a family. A button is not a kind of circle, and a chart is not a kind of text. No sensible parent class has a circle, a button and a chart as its children.

Inheritance alone leaves you stuck. Inheritance says “is a kind of”, and these things are not kinds of each other. What you want to say is looser: “each of these can be drawn, however differently each one does it”. You need a way to name a capability by itself, with no family attached.

Key idea

Inheritance answers “what is this thing?”. An interface answers “what can this thing do?”. Many designs need the second question answered more than the first.

An interface is a contract of behavior#

In its simplest form, an interface is a list of methods, each with a name, parameters and a return type but no body. It holds no fields of data. It says what must be possible, never how it is done. Read this one out loud:

Drawable says one thing: any class that claims to be drawable must have a method draw() that takes nothing and returns nothing. After draw() there is no body, only a semicolon. The program does nothing with Drawable yet; it shows that the interface compiles. The next section puts it to work.

Key idea

An interface is a promise. It names what a class must be able to do, and says nothing about how the class does it.

Keeping the promise with implements#

A promise is only worth something when someone keeps it. A class keeps an interface's promise with the keyword implements. Inheritance uses extendsto say “is a kind of”; a class uses implements to say “can do”. When a class says it implements Drawable, the compiler makes it provide a real draw() with a body, or the class does not compile. Here is a Circle that keeps the promise.

It prints Drawing a circle. Circle declared implements Drawable, so it had to define draw(), and it did. Notice that the method is marked public. Every method an interface declares is public, because the point of an interface is to advertise a capability to everyone, so the class that provides the method must make it public too.

Now add a second, unrelated class. A Square is not a kind of Circle and shares no parent with it, yet both can be drawn. Each one writes draw() its own way.

This prints Drawing a circle, then Drawing a square. Two classes with nothing else in common keep the same promise, each in its own way. That shared promise lets you treat them as one kind of thing, even though they share no family.

Polymorphism through the interface type#

Because both Circle and Square implement Drawable, a variable typed Drawable can hold either one. This is the upcasting you saw with polymorphism, except that the general type is now an interface instead of a parent class. The program can hold a thing by its capability and set aside what it actually is.

Step through it and watch d in the memory view. It is typed Drawable. First it points at Circle #1, so d.draw() prints Drawing a circle. Then the same variable is pointed at Square #1, and d.draw() prints Drawing a square. The declared type, Drawable, decided what you were allowed to call: just draw(). The real object decided which version ran. That is dynamic dispatch, working exactly as it did for classes.

Now put the whole idea in one loop. An array typed Drawable[] can hold circles and squares side by side, and one line draws them all.

The output is Drawing a circle, Drawing a square, Drawing a circle. The loop never mentions Circle or Square. It speaks only to the capability, Drawable, and each object answers in its own way. Add a Triangle that implements Drawable, put a new Triangle() in the array, and the loop draws it too, without a single change to the loop.

Key idea

Code written against an interface does not care what the real objects are, only that they keep the promise. You add new kinds by writing new classes, not by editing the code that uses them.

1public class Main {
2    public static void main(String[] args) {
3        Priced[] basket = { new Book("Dune", 9.5), new Coffee(), new Book("Emma", 6.0) };
4        double total = 0;
5 
6        // TODO: add up the price of every item in the basket
7 
8        System.out.println("Total: " + total);
9    }
10}
11 
12interface Priced {
13    double price();
14}
15 
16class Book implements Priced {
17    String title;
18    double cost;
19 
20    Book(String title, double cost) {
21        this.title = title;
22        this.cost = cost;
23    }
24 
25    public double price() {
26        return cost;
27    }
28}
29 
30class Coffee implements Priced {
31    public double price() {
32        return 3.0;
33    }
34}

Many capabilities at once#

A class can extend only one parent class, but it can implement as many interfaces as it likes, listed with commas. That fits what each one means. A thing has one identity, one answer to “what is it?”, but it can have many abilities.

Picture an on-screen button. It can be drawn, and it can be clicked: two separate capabilities. Write one interface for each, and a Button class promises both.

The output is Drawing a button, then Button clicked. Button said implements Drawable, Clickable, so the compiler required both draw() and click(), and the class provided both. A plain Circle might implement only Drawable, a checkbox might implement both, and a sound effect might implement only some Playable interface. Each class takes on exactly the capabilities it has.

Asking an object what it can do

To reach click() from a Drawable variable, ask the object first. instanceof works with interfaces just as it does with classes. Every item on this screen can be drawn, but only some can also be clicked.

It prints Drawing a circle, Drawing a button and Button clicked. The circle fails the instanceof Clickable test, so it is only drawn. The button passes, so the loop casts it to Clickable and clicks it: the same check-then-cast pattern you used for downcasting in polymorphism.

A parent class and interfaces together

A class can do both at once: extend one class and implement any number of interfaces. The extends part comes first. A duck is a kind of bird, so it extends Bird, and it can also swim and fly.

It prints I am Pip, Pip paddles across the pond and Pip flaps off. introduce() and the name field come from Bird, the one parent. swim() and fly() are the duck's answers to two promises. A Duck can now sit in a Bird variable, a Swimmer variable or a Flyer variable.

1public class Main {
2    public static void main(String[] args) {
3        Lamp lamp = new Lamp();
4        lamp.turnOn();
5        // TODO: dim the lamp to 40, then turn it off
6    }
7}
8 
9interface Switchable {
10    void turnOn();
11    void turnOff();
12}
13 
14interface Dimmable {
15    void dimTo(int percent);
16}
17 
18class Lamp implements Switchable {
19    public void turnOn() {
20        System.out.println("Lamp on");
21    }
22 
23    public void turnOff() {
24        System.out.println("Lamp off");
25    }
26 
27    // TODO: make Lamp Dimmable too
28}

Constants and default methods#

Two more features finish the picture. You will meet both in real code, so it is worth an honest look at each.

Constants in an interface

An interface can hold a named constant, a value that never changes and that every implementing class shares. A field written in an interface is automatically public (visible everywhere), static (one copy for the whole interface, not one per object) and final (set once, never changed). The best constants are part of the promise itself. Here, anything Adjustable promises to keep its level at or below MAX_LEVEL.

It prints Volume 7, then Volume 10, because Math.min caps the 15 at the maximum, then Loudest allowed: 10. Inside Speaker, the class can write plain MAX_LEVEL, since it implements the interface. Anywhere else you read it through the interface's name, Adjustable.MAX_LEVEL. Because it is final, any attempt to give it a new value is refused.

Default methods

Until Java 8, an interface could only hold methods without bodies. Java 8 added the default method: a method with a real body, marked with the keyword default. Every class that implements the interface gets the method for free, and may keep it or replace it. Default methods exist so that an interface can gain a new method without breaking the classes that already implement it. When Java 8 gave the List interface a new sort method, as a default, every list class written before then got it at once.

Circle wrote only draw(), yet it can call describe(), because the interface supplies a default body. A default method can also call the interface's other methods, even the ones without bodies, and a class can replace a default with its own version. Decide what this prints.

It prints Hello Sam, I am Robot, then Ahoy Sam!. Robot keeps the default greet, which calls name(), and name()runs the robot's own version: the same template idea you met with abstract classes. Pirate overrides greet, so its own version runs and the default is never used.

Main.java:20: error: types Swimmer and Walker are incompatible;
class Duck implements Swimmer, Walker {
^
  class Duck inherits unrelated defaults for move() from types Swimmer and Walker
1 error

What an interface can hold

Since Java 8 an interface can also have staticmethods, called on the interface's name the way you call Math.max, and since Java 9 it can have private methods, helpers that its default methods share and that no one outside can see. The table sums up what can go inside.

Interfaces you have already used#

Java's library is built on interfaces, and you have been using some without seeing their names. String and StringBuilder are unrelated classes, yet both implement an interface called CharSequence, a readable sequence of characters, which promises length() and charAt() among other methods. So one CharSequence variable can hold either.

It prints 5 characters, first is h, then 7 characters, first is b. There are more. The compareTo method from strings is how String keeps its promise to an interface called Comparable, which Java's sorting relies on; you write your own in Comparable, Comparator and sorting. And List is an interface too: ArrayList is one class that implements it, as the Collections Framework shows.

A first taste of interface versus abstract class#

You now know two tools that both make a class provide certain methods: the abstract class from the previous lesson and the interface from this one. They overlap, and choosing between them is a real skill. Here is the start of the comparison, enough to feel the difference.

Further reading#

• Interfaces, the dev.java tutorial on defining an interface
• Implementing an Interface, a dev.java worked example
• Using an Interface as a Type, on dev.java
• Interfaces in the Java Language Specification, chapter 9, including default, static and private methods