Certification Objective Implementing an Interface (Exam Objective 1.2)


Certification Objective —Implementing an Interface (Exam Objective 1.2)

1.2 Develop code that declares an interface

When you implement an interface, you're agreeing to adhere to the contract defined in the interface. That means you're agreeing to provide legal implementations for every method defined in the interface, and that anyone who knows what the interface methods look like (not how they're implemented, but how they can be called and what they return) can rest assured that they can invoke those methods on an instance of your implementing class.

For example, if you create a class that implements the Runnable interface (so that your code can be executed by a specific thread), you must provide the public void run() method. Otherwise, the poor thread could be told to go execute your Runnable object's code and—surprise surprise—the thread then discovers the object has no run() method! (At which point, the thread would blow up and the JVM would crash in a spectacular yet horrible explosion.) Thankfully, Java prevents this meltdown from occurring by running a compiler check on any class that claims to implement an interface. If the class says it's implementing an interface, it darn well better have an implementation for each method in the interface (with a few exceptions we'll look at in a moment).

Assuming an interface, Bounceable, with two methods: bounce(), and setBounceFactor(), the following class will compile:

 public class Ball implements Bounceable {  // Keyword                                            // 'implements'    public void bounce() { }    public void setBounceFactor(int bf) { } } 

OK, we know what you're thinking: "This has got to be the worst implementation class in the history of implementation classes." It compiles, though. And runs. The interface contract guarantees that a class will have the method (in other words, others can call the method subject to access control), but it never guaranteed a good implementation—or even any actual implementation code in the body of the method. The compiler will never say to you, "Um, excuse me, but did you really mean to put nothing between those curly braces? HELLO. This is a method after all, so shouldn't it do something?"

Implementation classes must adhere to the same rules for method implementation as a class extending an abstract class. In order to be a legal implementation class, a nonabstract implementation class must do the following:

  • Provide concrete (nonabstract) implementations for all methods from the declared interface.

  • Follow all the rules for legal overrides.

  • Declare no checked exceptions on implementation methods other than those declared by the interface method, or subclasses of those declared by the interface method.

  • Maintain the signature of the interface method, and maintain the same return type (or a subtype). (But it does not have to declare the exceptions declared in the interface method declaration.)

But wait, there's more! An implementation class can itself be abstract! For example, the following is legal for a class Ball implementing Bounceable:

 abstract class Ball implements Bounceable { } 

Notice anything missing? We never provided the implementation methods. And that's OK. If the implementation class is abstract, it can simply pass the buck to its first concrete subclass. For example, if class BeachBall extends Ball, and BeachBall is not abstract, then BeachBall will have to provide all the methods from Bounceable:

 class BeachBall extends Ball {   // Even though we don't say it in the class declaration above,   // BeachBall implements Bounceable, since BeachBall's abstract   // superclass (Ball) implements Bounceable    public void bounce() {       // interesting BeachBall-specific bounce code    }    public void setBounceFactor(int bf) {       // clever BeachBall-specific code for setting       // a bounce factor    }   // if class Ball defined any abstract methods,   // they'll have to be   // implemented here as well. } 

Look for classes that claim to implement an interface but don't provide the correct method implementations. Unless the implementing class is abstract, the implementing class must provide implementations for all methods defined in the interface.

Two more rules you need to know and then we can put this topic to sleep (or put you to sleep; we always get those two confused):

  1. A class can implement more than one interface. It's perfectly legal to say, for example, the following:

     public class Ball implements Bounceable, Serializable, Runnable {...} 

You can extend only one class, but implement many interfaces. But remember that subclassing defines who and what you are, whereas implementing defines a role you can play or a hat you can wear, despite how different you might be from some other class implementing the same interface (but from a different inheritance tree). For example, a Person extends HumanBeing (although for some, that's debatable). But a Person may also implement Programmer, Snowboarder, Employee, Parent, or PersonCrazyEnoughToTakeThisExam.

  1. An interface can itself extend another interface, but never implement anything. The following code is perfectly legal:

     public interface Bounceable extends Moveable { }   //ok! 

What does that mean? The first concrete (nonabstract) implementation class of Bounceable must implement all the methods of Bounceable, plus all the methods of Moveable! The subinterface, as we call it, simply adds more requirements to the contract of the superinterface. You'll see this concept applied in many areas of Java, especially J2EE where you'll often have to build your own interface that extends one of the J2EE interfaces.

Hold on though, because here's where it gets strange. An interface can extend more than one interface! Think about that for a moment. You know that when we're talking about classes, the following is illegal:

 public class Programmer extends Employee, Geek { } // Illegal ! 

As we mentioned earlier, a class is not allowed to extend multiple classes in Java. An interface, however, is free to extend multiple interfaces.

 interface Bounceable extends Moveable, Spherical {   // ok!    void bounce();    void setBounceFactor(int bf); } interface Moveable {    void moveIt(); } interface Spherical {    void doSphericalThing(); } 

In the next example, Ball is required to implement Bounceable, plus all methods from the interfaces that Bounceable extends (including any interfaces those interfaces extend, and so on until you reach the top of the stack—or is it the bottom of the stack?). So Ball would need to look like the following:

 class Ball implements Bounceable {    public void bounce() { }   // Implement Bounceable's methods    public void setBounceFactor(int bf) { }    public void moveIt() { }    // Implement Moveable's method    public void doSphericalThing() { }   // Implement Spherical } 

If class Ball fails to implement any of the methods from Bounceable, Moveable, or Spherical, the compiler will jump up and down wildly, red in the face, until it does. Unless, that is, class Ball is marked abstract. In that case, Ball could choose to implement any, all, or none of the methods from any of the interfaces, thus leaving the rest of the implementations to a concrete subclass of Ball, as follows:

 abstract class Ball implements Bounceable {    public void bounce() { ... }  // Define bounce behavior    public void setBounceFactor(int bf) { ... }    // Don't implement the rest; leave it for a subclass } class SoccerBall extends Ball {  // class SoccerBall must              // implement the interface methods that Ball didn't    public void moveIt() { ... }    public void doSphericalThing() { ... }    // SoccerBall can choose to override the Bounceable methods    // implemented by Ball    public void bounce() { ... } } 

Figure 2-5 compares concrete and abstract examples of extends and implements, for both classes and interfaces.

image from book
Figure 2-5: Comparing concrete and abstract examples of extends and implements

image from book
Exam Watch

Look for illegal uses of extends and implements.The following shows examples of legal and illegal class and interface declarations:

 class Foo { }                      //OK class Bar implements Foo  { }      //No! Can't implement a class interface Baz { }                  //OK interface Fi { }                   // OK interface Fee implements Baz { }   //No! Interface can't                                    // implement an interface interface Zee implements Foo { }   //No! Interface can't                                    // implement a class interface Zoo extends Foo { }      //No! Interface can't                                    // extend a class interface Boo extends Fi { }       // OK. Interface can extend                                    // an interface class Toon extends Foo, Button { } //No! Class can't extend                                    // multiple classes class Zoom implements Fi, Fee { }  // OK. class can implement                                    // multiple interfaces interface Vroom extends Fi, Fee { }  // OK. interface can extend                                      // multiple interfaces class Yow extends Foo implements Fi { } // OK. Class can do both                                         // (extends must be 1st) 

Burn these in, and watch for abuses in the questions you get on the exam. Regardless of what the question appears to be testing, the real problem might be the class or interface declaration. Before you get caught up in, say, tracing a complex threading flow, check to see if the code will even compile. (Just that tip alone may be worth your putting us in your will!) (You'll be impressed by the effort the exam developers put into distracting you from the real problem.) (How did people manage to write anything before parentheses were invented?)

image from book



SCJP Sun Certified Programmer for Java 5 Study Guide Exam 310-055
SCJP Sun Certified Programmer for Java 5 Study Guide (Exam 310-055) (Certification Press)
ISBN: 0072253606
EAN: 2147483647
Year: 2006
Pages: 131

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net