If you’ve done any GUI programming in Java, you’ve likely already implemented an interface. Odds are also good you don’t know why, as the subject of interfaces is seldom clearly explained.
Put simply, an interface is a list of abstract method signatures. When it is implemented by a class, that class must define each method in the list, or the class itself must be declared abstract. For example, when you implement Java’s KeyListener interface, you must define the methods keyTyped, keyPressed and keyReleased to specify how your application will react to those keyboard events. Let’s take a look at how this interface forces us to conform to specifications:
Suppose you have written a class called myApplication that extends JFrame and implements KeyListener. Just as myApplication is a JFrame (under the rules of the class hierarchy), myApplication is also a KeyListener. Assuming your class has successfully overridden all of the methods that are declared in the interface, you still must add the following line of code:
addKeyListener(this);
addKeyListener is a method in the Component class, inherited through many levels of the class hierarchy. It accepts data type KeyListener as an argument. The this keyword refers to the current class ( myApplication). Because myApplication is a KeyListener, the data types are compatible and the addKeyListener method executes properly. To clarify: only a KeyListener can make use of the addKeyListener method. In order to become a KeyListener, a class must implement the KeyListener interface and override its methods. This ensures that any class that will use a KeyListener to catch keyboard events includes methods that detail how the application will respond to them.
Although Java does not support multiple class inheritance (you may only extend one class), you can implement as many interfaces as you wish. In addition to KeyListener, most GUI applications will also implement MouseListener and WindowListener, for example. Interfaces exist separately from the class hierarchy. This contributes to their usefulness, especially in creating polymorphic code.
The word polymorphism just sounds complicated. In school, they taught us just enough about it to be able to use it in a sentence. The idea is, it’s supposed help us impress a prospective employer who won’t have any idea what we’re talking about anyway. I touched on polymorphism in my last column in a similarly superficial fashion, but now I’d like to discuss it in more depth, as it pertains to interfaces.
The true power of polymorphism (or dynamic binding) is extensibility. If your program processes objects polymorphically, you can later add additional object types without modifying the process code. You don’t necessarily need to know at design time what objects your program will ultimately be handling.
A construction site would include many different types of workers. There may be excavators, crane operators, steelworkers, etc. Let’s create an interface called constructionWorker that we can use to relate them all. We’ll define abstract method startWork in the interface, to ensure that every constructionWorker knows how to start his job.
public interface constructionWorker {
public void startWork();
}
This file would be saved as constructionWorker.java.
Assuming each worker object created implements constructionWorker and overrides startWork, we can store them all in a single array of type constructionWorker in a Foreman class.
It is now possible to iterate through the array of workers, calling the startWork method for each element. Through polymorphism, Java knows what type of object each element is, and calls its specific, overridden startWork method.
Here’s the analogy: The foreman yells “Start work!” and all the different workers begin working in their own unique way. In order for the foreman to yell “Start work!” he doesn’t have to know what workers he has on site. If a new worker with a new task should join the team later, the foreman is still going to bellow out the same phrase every morning. In Java terms, this means that the code for the Foreman class will not need to be changed no matter how many different types of objects are created to be under its control.
Now that you can do more with polymorphism than just use it in a sentence, you’ll have one up on the college students at job interview time.
Part five of this series will deal with graphics.
Cooney is a Toronto-based programmer and a freelance Internet developer. He is currently enrolled in Humber College’s Computer Programmer program. He can be reached at robert_cooney@hotmail.com.