This chapter is from the book
This chapter is from the book
This chapter is from the book
Implementing Interfaces
You have to do two things to implement an interface. You have to announce that your class will implement the interface in your class declaration, like this:
public class SuperHero implements IFly {...}
Then, you have to implement each method defined in an interface. Most IDEs, including Eclipse, will tell you the names of the methods you need to implement as a convenience. Note that whether you have implemented each method you're supposed to is checked at compile time, not at runtime.
FridgeI
It is a naming convention that you'll often see to prefix "I" before the name of an interface in order to identify it easily as an interface. If you've programmed in VB, you're probably used to Hungarian notation, which serves a similar purpose.
Remember that the purpose of an interface is to say that the implementing class must have methods that match the signatures. That doesn't say anything about the quality of the implementation. Say we have an interface called IFly (which we'll define next), and it has one method void accelerate(int speed);. The following is legal, and will compile:
public class SuperHero implements IFly {
public void accelerate(int i) {}
}
This can be convenient if an interface has a method or two that you don't really need. But if you find yourself doing this sort of thing with any frequency, you might take a second look at whether you really ought to be implementing that interface, and if there isn't some other way to solve the problem. If you are the designer of the interface, you might want to reexamine your interface design to make sure that you are defining what users (in this context, programmers who want to implement your interface, including you) really need. By the same token, if you find in your code a number of methods that programmers need to define over and over again, consider moving them into the interface and making them part of the contract. This could have the effect of tightening and strengthening your abs. I mean your API.
A class can implement more than one interface. Separate each interface with a comma in the class declaration, like this:
public class RockStar implements IGuitarPicker,
ILeatherPantsWearer { }
Abstract Class Implementation of Interfaces
This is something very weird. Actually, I'll pose it as a question and see what you think. Previously, we had our IFly interface, and our regular old class SuperHero implemented it.
(Deep, oily announcer voice) For 50 points, can an abstract class implement an interface? (After slight pause, with greater significance) Can an abstract class implement an interface?
Think about it (after all, it's worth 50 points). Can an abstract class implement anything? Actually, yes, it can. It can have both abstract and concrete methods. So the answer must be yes. Because you can do this:
public abstract class SuperHero implements IFly {
public void accelerate(int speed) {
// some code here to do accelerating...
}
}
Any class that extends SuperHero will inherit this functionality, or alternatively, it can decide to override the accelerate() method if it wants to, and define a different implementation.
That was easy enough. But here's the killer: Is the following legal?
public abstract class SuperHero implements IFly { }
Notice that there is not only no mention of the accelerate() method, there is no code at all. How could an abstract class say it implements an interface that it doesn't implement? It must be wrong!
Actually1, that code compiles without a problem. Because there is another contract at work when you define an abstract class, and that contract is that the interface methods must have been implemented by the first concrete subclass of the abstract class. The first concrete class is not required to implement all of them, just those that have not been previously implemented by some abstract class that implements the interface up the hierarchy. The following series of classes is legal and compiles.
IFly.java
public interface IFly {
void accelerate(int speed);
void slowDown(int speed);
}
Now an abstract class will say it implements the IFly interface.
SuperHero.java
public abstract class SuperHero implements IFly { }
JusticeLeagueSuperHero.java
public abstract class JusticeLeagueSuperHero
extends SuperHero { public void accelerate(int speed) { //some real implementation code! System.out.println("Accelerating to " + speed + "mph"); } }
Notice that JusticeLeagueSuperHero implements the accelerate () method, but not the slowDown() method, which is also required by the interface. The code compiles because it is also declared abstract, and it is expected that one day someone will want to make a concrete subclass of JusticeLeagueSuperHero, so that you can say new SuperHero() and get to work. Of course, if no one ever makes a concrete subclass that implements the slowDown() method, the interface is not really implemented, even though we said it was. But that couldn't matter less, because we can't ever make any objects.
So now let's look at the final class in our implementation of this interface, the concrete class SomeMoreSpecificSuperHero.
SomeMoreSpecificSuperHero.java
public class SomeMoreSpecificSuperHero
extends JusticeLeagueSuperHero {
public void slowDown(int speed) {
//some real implementation code here!
System.out.println("Slowing down to " + speed " mph");
}
}
In our little hierarchy, we have an interface, an abstract class (SuperHero) that implements the interface but doesn't actually implement any methods, a second abstract class (JusticeLeagueSuperHero) that extends SuperHero and provides a concrete implementation of one method in the interface, and then our first concrete class (SomeMoreSpecificSuperHero) that extends JusticeLeagueSuperHero and implements the remaining method. By the time we get to the concrete class, everything has an implementation. Cool.
Well, I'm going to get a beer and make a pizza. Thanks for talking about interfaces with me. I'm feeling much better now.