Certification Objective Declare Interfaces (Exam Objectives 1.1 and 1.2)


Certification Objective —Declare Interfaces (Exam Objectives 1.1 and 1.2)

1.1 Develop code that declares classes (including abstract and all forms of nested classes), interfaces, and enums, and includes the appropriate use of package and import statements (including static imports).

1.2 Develop code that declares an interface. Develop code that implements or extends one or more interfaces. Develop code that declares an abstract class. Develop code that extends an abstract class.

Declaring an Interface

When you create an interface, you're defining a contract for what a class can do, without saying anything about how the class will do it. An interface is a contract. You could write an interface Bounceable, for example, that says in effect, "This is the Bounceable interface. Any class type that implements this interface must agree to write the code for the bounce() and setBounceFactor() methods."

By defining an interface for Bounceable, any class that wants to be treated as a Bounceable thing can simply implement the Bounceable interface and provide code for the interface's two methods.

Interfaces can be implemented by any class, from any inheritance tree. This lets you take radically different classes and give them a common characteristic. For example, you might want both a Ball and a Tire to have bounce behavior, but Ball and Tire don't share any inheritance relationship; Ball extends Toy while Tire extends only java.lang.Object. But by making both Ball and Tire implement Bounceable, you're saying that Ball and Tire can be treated as, "Things that can bounce, " which in Java translates to "Things on which you can invoke the bounce() and setBounceFactor() methods." Figure 1-1 illustrates the relationship between interfaces and classes.

image from book
Figure 1-1: The Relationship between interfaces and classes

Think of an interface as a 100-percent abstract class. Like an abstract class, an interface defines abstract methods that take the following form:

 abstract void bounce();  // Ends with a semicolon rather than                          // curly braces 

But while an abstract class can define both abstract and non-abstract methods, an interface can have only abstract methods. Another way interfaces differ from abstract classes is that interfaces have very little flexibility in how the methods and variables defined in the interface are declared. These rules are strict:

  • All interface methods are implicitly public and abstract. In other words, you do not need to actually type the public or abstract modifiers in the method declaration, but the method is still always public and abstract.

  • All variables defined in an interface must be public, static, and final—in other words, interfaces can declare only constants, not instance variables.

  • Interface methods must not be static.

  • Because interface methods are abstract, they cannot be marked final, strictfp, or native. (More on these modifiers later.)

  • An interface can extend one or more other interfaces.

  • An interface cannot extend anything but another interface.

  • An interface cannot implement another interface or class.

  • An interface must be declared with the keyword interface.

  • Interface types can be used polymorphically (see Chapter 2 for more details).

The following is a legal interface declaration:

 public abstract interface Rollable { } 

Typing in the abstract modifier is considered redundant; interfaces are implicitly abstract whether you type abstract or not. You just need to know that both of these declarations are legal, and functionally identical:

 public abstract interface Rollable { } public interface Rollable { } 

The public modifier is required if you want the interface to have public rather than default access.

We've looked at the interface declaration but now we'll look closely at the methods within an interface:

 public interface Bounceable {     public abstract void bounce();     public abstract void setBounceFactor(int bf); } 

Typing in the public and abstract modifiers on the methods is redundant, though, since all interface methods are implicitly public and abstract. Given that rule, you can see that the following code is exactly equivalent to the preceding interface:

 public interface Bounceable {       void bounce();                 // No modifiers       void setBounceFactor(int bf);  // No modifiers } 

You must remember that all interface methods are public and abstract regardless of what you see in the interface definition.

Look for interface methods declared with any combination of public, abstract, or no modifiers. For example, the following five method declarations, if declared within their own interfaces, are legal and identical!

 void bounce(); public void bounce(); abstract void bounce(); public abstract void bounce(); abstract public void bounce(); 

The following interface method declarations won't compile:

 final void bounce();    // final and abstract can never be used                         // together, and abstract is implied static void bounce();   // interfaces define instance methods private void bounce();  // interface methods are always public protected void bounce();    // (same as above) 

Declaring Interface Constants

You're allowed to put constants in an interface. By doing so, you guarantee that any class implementing the interface will have access to the same constant.

By placing the constants right in the interface, any class that implements the interface has direct access to the constants, just as if the class had inherited them.

You need to remember one key rule for interface constants. They must always be

 public static final 

So that sounds simple, right? After all, interface constants are no different from any other publicly accessible constants, so they obviously must be declared public, static, and final. But before you breeze past the rest of this discussion, think about the implications: Because interface constants are defined in an interface, they don't have to be declared as public, static, or final. They must be public, static, and final, but you don't have to actually declare them that way. Just as interface methods are always public and abstract whether you say so in the code or not, any variable defined in an interface must be—and implicitly is—a public constant. See if you can spot the problem with the following code (assume two separate files):

 interface Foo {   int BAR = 42;   void go(); } class Zap implements Foo {   public void go() {      BAR = 27;   } } 

You can't change the value of a constant! Once the value has been assigned, the value can never be modified. The assignment happens in the interface itself (where the constant is declared), so the implementing class can access it and use it, but as a read-only value. So the BAR = 27 assignment will not compile.

image from book
Exam Watch

Look for interface definitions that define constants, but without explicitly using the required modifiers. For example, the following are all identical.

 public int x = 1;        // Looks non-static and non-final,                          // but isn't! int x = 1;               // Looks default, non-final,                          // non-static, but isn't! static int x = 1;        // Doesn't show final or public final int x = 1;         // Doesn't show static or public public static int x = 1;        // Doesn't show final public final int x = 1;         // Doesn't show static static final int x = 1          // Doesn't show public public static final int x = 1;  // what you get implicitly 

Any combination of the required (but implicit) modifiers is legal, as is using no modifiers at all! On the exam, you can expect to see questions you won't be able to answer correctly unless you know, for example, that an interface variable is final and can never be given a value by the implementing (or any other) class.

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