Notice: This material is excerpted from Special Edition Using Java, ISBN: 0-7897-0604-0. The electronic version of this material has not been through the final proof reading stage that the book goes through before being published in printed form. Some errors may exist here that are corrected before the book is published. This material is provided "as is" without any warranty of any kind.
by Michael Afergan
While classes define objects, interfaces help to define classes. Somewhat resembling classes in syntax, interfaces are used when you want to define a certain functionality to be used in several classes, but are not sure exaclty how this functionality will be defined by these classes. By placing such methods in an interface you are able to outline common behavior and leave the specific implementation to the classes themselves.
Interfaces are Java's substitute for C++'s feature of multiple inheritance, the practice of allowing a class to have several superclasses. While it is often desirable to have a class inherit several sets of properties, for several reasons, the creators of Java decided not to allow multiple inheritance. Java classes, however, can implement several interfaces, thereby enabling you to create classes that build upon other objects without the problems created by multiple inheritance.
Although not very complex, interfaces are rather useful. In this chapter we will discuss:
Before we can use an interface, we must first develop it. As we will see, the syntax and process for doing so resembles that of classes quite closely and is very uncomplicated.
Interfaces are the underprivileged first cousins of classes. While classes have the ability to define an object, interfaces define a set of methods and constants to be implemented by another object. From a practical viewpoint, interfaces help to define the behavior of an object by declaring a set of characteristics for the object. For example, knowing that a person is an athlete does not define their entire personality, but does ensure that they will have certain traits and abilities. Thus, by later implementing an interface, you ensure that a class will posses these abilities.
Interfaces define only abstract methods and final fields, but cannot specify any implementation for these methods. As a result, like abstract classes, it is the responsibility of any classes that implement an interface to specify the implementation of these methods.
In general, interfaces enable you as a programmer to define a certain set of functionality without having any idea as to how this functionality will be later defined. As an example, the java.lang.Runnable interface provides you with a tremendous amount of power and flexibility. That is partly because although it defines one method, run(), it places no limitations on the way in which you may define run() in other classes.Therefore, you may place virtually anything within the run() method of your class and still have it treated as a class implementing the Runnable interface. When developing a class that implements an interface, you are able to develop the class-specific implementation of these methods. Consequently, when using such classes, you are able to depend on the fact that these methods will be implemented, without having to worry about how these methods are implemented.
Another excellent example is the java.applet.AppletContext interface. The interfaces defines a set of methods that return information regarding the environment in which an applet is running, such as the appletviewer or a web browser. While the java.applet.Applet class depends on the methods declared in the AppletContext interface, it nevertheless does not need to worry about how these methods obtain their information but can be assured that they will somehow. Therefore, we can use the same applet class and the same methods (such as java.applet.Applet.showStatus()) in a variety of environments without worrying about how these methods are implemented.
The syntax for creating an interface is extremely similar to that for creating a class. However there are a few exceptions. Most significant is the fact that none of the methods in your class may have a body, nor may you declare any variables that will not serve as constants. Nevertheless, there are some important things that you may include in a interface definition.
Here is an example of an interface, a class that implements the interface, and a class that uses the derived class. Look it over to get an idea as to how interfaces are used and where we are going in this chapter. As we go on, we will throughly examine each portion.
Listing 11.1 An Application of an Interface
interface Product {
static final String MAKER = "My Corp";
static final String PHONE = "555-123-4567";
public int getPrice(int id);
}
class Shoe implements Product {
public int getPrice(int id) {
if (id == 1)
return(5);
else
return(10);
}
public String getMaker() {
return(MAKER);
}
}
class Store {
static Shoe hightop;
public static void init() {
hightop = new Shoe();
}
public static void main(String argv[]) {
init();
getInfo(hightop);
orderInfo(hightop);
}
public static void getInfo(Shoe item) {
System.out.println("This Product is made by "+ item.MAKER);
System.out.println("It costs $" + item.getPrice(1) + '\n');
}
public static void orderInfo(Product item) {
System.out.println("To order from " +item.MAKER + " call " + item.PHONE + ".");
System.out.println("Each item costs $" + item.getPrice(1));
}
}
Interface declarations have the syntax:
public interface NameofInterface extends InterfaceList
where everything in italics is optional.
By default, interfaces may be implemented by all classes in the same package. By making your interface public, you allow classes and objects outside of the given package to implement it as well.
Like public classes, public interfaces must be defined in a file named <NameofInterface>.java.
The rules for an interface name are identical to those for classes.
The only requirements on the name are that it begin with a letter, an underscore
character, or a dollar sign, contain only Unicode characters (basic letters
and digits, as well as some other special characters), and not be the same
as any Java keyword (i.e., extends or int). Again, like classes, it is
common practice to capitalize the first letter of any interface name.
Additionally, while only required for public interfaces, it is a good practice to place all interfaces in a file named <NameofInterface>.java. This will enable both you and the Java compiler to find the source code for your class.
Thus, while the Product interface is not public, we should still declare it in a file named Product.java.
In accordance with the OOP theory of inheritance, Java interfaces may also extend other interfaces as a means of further developing previously coded interfaces. The new sub-interface will inherit all the methods and static constants of the super-interfaces in the same manner as how subclasses inherit the properties of superclasses.
While interfaces are allowed to extend other interfaces, because they cannot define any methods, interfaces may not define the methods declared in the interfaces that they extend. Instead, it will be the responsibility of any class that implements the derived interface to define both the methods declared in the derived interface and any methods defined in the extended interfaces.
As an example, the following lines are the declarations of two sperate interfaces, each of which entends a previously defined interface:
interface MonitoredRunnable extends java.lang.Runnable interface NetworkedDataOuput extends java.io.DataOuput
The first declares could be used to create an more detailed Runnable interface, perhaps including some of the features that can be found in java.lang.Thread.
The second declaration could belong to an interface defining an additional set of methods pertaining to network communications. Both these methods and the methods declared in the java.io.DataOutput interface would be found in any classes implementing the new NetworkedDataOutput interface.
Interfaces cannot extend classes.
Remember that if you implement an extended interface, you must override both the methods in the new interface and the methods in the old interface as seen in listing 11.2.
Listing 11.2 Implementing a Derived Interface
interface MonitoredRunnable extends java.lang.Runnable {
public boolean isRunning();
}
class Fireworks implements MonitoredRunnable {
private boolean running; // keeps track of state
void run() {
shootFireWorks();
}
boolean isRunning() { // provides access to other objects without
return(running); //allowing them to change the value of running
}
}
Note that since Fireworks implements MonitoredRunnable it must override isRunning(), declared in MonitoredRunnable, and run(), declared in Runnable.
Note
Notice that while classes implement interfaces as a means of inheriting their properties, interfaces extend other interfaces. This is because the extends keyword allows for further development of code while the implements keyword simply causes a given class to acquire the properties of an interface.
end note
If extending more than one interface, separate each by a comma.
While it cannot specify any specific implementation, the body of an interface does specify its properties. While a majority of the benefits of interfaces come from their ability to declare methods, interfaces may also posses final variables.
For example, by declaring the MAKER variable in the Product interface, we declare a constant that will be employed by all classes implementing the Product interface.
Another nice example of final fields in interfaces can be found in the java.awt.image.ImageConsumer interface. The interface defines a set of final integers that will serve as standards for interpreting information. Because the RANDOMPIXELORDER variable equals 1, classes that implement the ImageConsumer interface will be able to understand that the value of 1 means that the pixels will be sent in a random order.
The main purpose of interfaces is to declare abstract methods that will be defined in other classes. As a result, if you are dealing with a class that implements an interface, you can be assured that these methods will be defined in the class. While this process is not overly complicated, there are some important that should be noticed.
The syntax for declaring a method in an interface is extremely similar to declaring a method in a class. The only significant difference is that in contrast to methods declared in classes, methods declared in interfaces have cannot posses bodies.
As stated above, an interface method consists of only a declaration. For example, the following two methods are complete if they are defined in an interface:
public int getPrice(int id);
public void showState();
However in a class, they would require method bodies:
public int getPrice(int id) {
if (id == 1)
return(5);
else
return(10);
}
public void showState() {
System.out.println("Massachusetts");
}
While the method declaration does not determine how a method will behave, it nevertheless defines its behavior by defining what information it needs and what (if any) information will be returned. Since the method implementations will be dependent on the methods declarations specified in the interface, it is important that you consider the necessary properties of the method-its return value, parameters, and exception list-and how they will impact the rest of your code.
Method declarations in interfaces have the following syntax:
public return_value nameofmethod (parameters) throws ExceptionList;
where everything in italics is optional. Also note that unlike normal method declarations in classes, declarations in interfaces are immediately followed by a semicolon.
Note that method declarations in interfaces resemble method declarations in Java classes and function declarations in C++ classes.
While it is possible to use the keyword public when declaring methods, all methods in interfaces are naturally public regardless of the presence or absence of the public modifier.
Also note you may not use any of the other standard method modifiers, (including native, static, synchronized, final, private, protected, or private protected) when declaring a method in an interface.
Although interfaces are generally employed to provide abstract implementation of methods, they may also posses variables. Nevertheless, because you cannot place any code within the bodies of the methods, all variables declared in an interface must be fields global to the class. Furthermore, regardless of the modifiers used when declaring the field, all fields declared in an interface are always public, final, and static.
While all fields will be created as public, final, and static, you do not need to explicitly state this in the field declaration. All fields will be created as public, static and final regardless of the presence of these modifiers.
Nevertheless it is good practice to explicity define all fields in interfaces as public, final, and static to remind yourself (and other programmers) of this fact.
As seen in the Product interface above, interface fields, like final static fields in classes, are used to define constants that can be accessed by all classes that implement the interface.
Lastly, since all fields are final, they must be initialized when they are declared the interface itself.
Now that we have seen how to create interfaces, let us examine how they are used in developing classes. Here is an example of a class that implements our Product interface:
Listing 11.3 Implementing an Interface
class Shoe implements Product {
public int getPrice(int id) {
if (id == 1)
return(5);
else
return(10);
}
public String getMaker() {
return(MAKER);
}
}
Of course, the code in the class can deal with functions other than those relating to the interface. Nevertheless, in order to fulfil the requirements of implementing the Product interface, the class must override the getPrice(int) method inasmuch as it is originally declared in the interface. Because it is the only method declared in the interface, it therefore is the only method that must be found in the Shoe class.
As we have seen, declaring a method in an interface is often a good practice. However, the method cannot be used until it is overriden in a class implementing the given method.
A method declaration in an interface determines much of the method's behavior by defining such things as the method name, return type, and parameter signature. However, when overriding such a method, there are also several aspects that may be changed. In fact, the only part of the method that cannot change is its name.
begin tip
Remember that if you implement an interface, you are required to override all methods declared in the interface. .Failure to do so will make your class abstract.
end tip
As discussed earlier, methods declared in interfaces are by default assigned the public level of access. Because you cannot override a method to be more private than it already is, all methods declared in interfaces and overridden in classes must be assigned the public access modifier.
Of the remaining modifiers that may be applied to methods, only native and abstract may be applied to methods originally declared in interfaces.
Interface methods define a set a of parameters that must be passed to the method. Consequently, declaring a new method with the same name but a different set of parameters than the method declared in your interface will overload the method, not override it.
While there is nothing wrong with overloading methods declared in interfaces, remember that it is also important to implement the method declared in the interface. Therefore, unless you declare your class to be abstract, you must override each method, employing the same parameter signature asin your interface. This means that while the names of the variables may change, their order and types may not.
If the method String createName(int length, boolean capitalized) is declared in an interface, here are some valid and invalid examples of how to override it.
| Valid | Invalid |
|---|---|
| String createName(int a, boolean b) | String createName(boolean capitalized, int length) |
| String createName(int width, boolean formatted) | String createName(int length) |
In Java, the term "exception" has two definitions. In a general sense, an exception is an unwanted occurrence. Every programmer, through instruction or experience, learns that it is a good idea to place error-handling code in every program to prevent such things as improper input and division by 0. Such unwanted and undefined functions must be handled.
Java has special constructs for handling such problems. Java Exceptions are objects created when an exception is encountered. These objects are then returned from the method to the calling object and must be dealt with. This process of returning exceptions is called "throwing" exceptions and is performed with a throw statement. Dealing with exceptions is called "catching," and is accomplished by placing statements that may throw exceptions in a try-catch block.
In order to throw an exception, the exception type (or one of its superclasses) must be listed in the exception list for the method. However, when dealing with interface methods, exceptions are an exception. Here are the rules for overriding methods that throw exceptions:
In general, the exception list of the method declared in the interface, not the re-declared method determines which expectations can and cannot be thrown.
While it is good practice to list those exceptions that the new method may throw in the class declaration of the method, you do not need to include an exception list in the re-declaration of methods first declared in interfaces.
As an example, examine the interface and method declarations in listing 11.4.
Listing 11.4 Alternate Exception Lists
interface Example {
public int getPrice(int id) throws java.lang.RuntimeException;
}
class User implements Example {
public int getPrice(int id) throws java.awt.AWTException { // Illegal - Reason 1
// java.awt.AWTException is not a subclass ofjava.lang.RuntimeException
/// method body
}
public int getPrice(int id) {
if (id == 6)
throw new java.lang.IndexOutOfBoundsException(); // Legal - Reason 2
//IndexOutOfBoundsException is derived from RuntimeException
else
...
}
public int getPrice(int id) throws java.lang.IndexOutOfBoundsException { // Legal - Reason 1
// IndexOutOfBoundsException is derived from RuntimeException
if (id == 6)
throw new java.lang.ArrayIndexOutOfBoundsException(); // Legal - Reason 3
// ArrayIndexOutOfBoundsException is derived from IndexOutOfBoundsException
...
}
When creating a class that implements an interface, one of your chief concerns will be the creation of bodies for the methods originally declared in the interface. Unless you decide to make the method native, it is necessary to create the body for every method originally declared in your interface if you do not wish to make your new class abstract. Nevertheless, the actual implementation and code of the body of your new method is entirely up to you. This is one of the nice things about using interfaces. While the interface ensure that in a non-abstract class, its methods will be defined and will return an appropriate data type, the interface places no further restrictions or limitations on the method bodies.
Begin Note
While a non-abstract class that implements an interface is assured to posses every method declared in the interface, it does not assure you that these methods will be implemented properly. In fact, creating a method body consisting simply an opening and closing curly brace ({ }) will satisfy the requirements of a method whose return type is void.
While doing this will trick the compiler into believing that you have satisfied the requirements of implementing an interface, doing so can create many problems. As we will later see, we can perform nice operations with classes that implement interfaces because we know that every method in the interface is implemented in the class. However, if the method exists in name only, we will not obtain the desired result.
Consequently, do not cheat yourself by overriding interface methods with inadequate method bodies. If for some reason you are unable to create an effective method, rethink your use of the interface.
end note (c) Using interfaces from other classes
We have examined how to create interfaces and how to build classes based on interfaces. However, interfaces are not useful unless we are able to develop classes that will either employ the derived classes or the interface itself.
As we will see there are several ways in which classes that implement interfaces can be employed in other classes. Nevertheless, all uses hinge one certain ability: being assured of the fact that the methods and fields declared in the interface will be defined in the given class.
Although the fields of an interface must be both static and final, they nevertheless can be extremely useful in your code. As discussed earlier, they must serve as constants, but even in this limited role, as seen in listing 11.5 and listing 11.6, they serve to clarify your code and provide with with valuable information.
As seen in the following example, any field of a interface may be refrenced using the standard dot notation as InterfaceName.field. This will provide you with access to descriptive constants (as seen in 11.5), as well as information (such as MAKER in the Product interface).
Listing 11.5 Using the Constant Fields of an Interface
class MyImageHandler {
/* The java.awt.image.ImageConsumer interface defines certain constants to serve as indicators.
STATICIMAGEDONE, which is set to equal 3, informs the consumer that the image is complete.*/
ImageConsumer picture;
void checkStatus(boolean done) {
if (done)
picture.imageComplete(ImageConsumer.STATICIMAGEDONE);
}
}
Because STATICIMAGEDONE is a public field of the ImageConsumer interface it may be refrenced as ImageConsumer.STATICIMAGEDONE.
Another nice feature of interfaces is the fact that any instance of a class that implements a given interface must posses the abstract methods declared in the interface. (If the class did not override and implement these methods, it would be abstract and thus you could not create an instance of it.) Consequently, it is possible to refer to types of objects that implement a given interface inasmuch as they will all posses a common set of methods. Although the classes may differ significantly in their task and implementation, classes that implement a given interface may be dealt with in a similar manner without any worry as to how the methods are implemented.
In the following example, we create a simple application that employs the Shoe class developed earlier. Because the Shoe class implements the Product interface, we may deal with the instances of the Shoe class either as standard Shoe objects or as objects based on the Product interface. Although both approaches produce the same results, treating the instance of Shoe as an object based on the Product interface provides us with a more flexible and useful way of using the resources provided by the Product interface.
Listing 11.6 Using an Interface as a Paramter Type
class Store {
static Shoe hightop;
public static void init() {
hightop = new Shoe();
}
public static void main(String argv[]) {
init();
getInfo(hightop);
orderInfo(hightop);
}
public static void getInfo(Shoe item) {
System.out.println("This Product is made by "+ item.MAKER);
System.out.println("It costs $" + item.getPrice(1) + '\n');
}
public static void orderInfo(Product item) {
System.out.println("To order from " +item.MAKER + " call " +
[ic:ccc]item.PHONE + ".");
System.out.println("Each item costs $" + item.getPrice(1));
}
}
Output:
C:\dev>\jdk\java\bin\java Store
This Product is made by My Corp
It costs 5
To order from My Corp call 555-123-4567.
Each item costs 5
In the above example, the getInfo() methods treats hightop as a simple class with certain methods and fields. However, the interesting example is orderInfo(), which extracts almost the same information without knowing anything about a Shoe. Since a Shoe meets the requirements of a Product, we are able to implicitly cast a Shoe to become a Product. As a result, since we know that the Product interface declares certain features, we can be sure that these features, such as the getPrice() method, are present in the parameter item.
begin Note
You will notice that in treating hightop as a Product, we are implicitly casting it as a new data type without specifically stating so in our code. While the compiler has no trouble in doing this, we could substitute that line of code in the Store class for the following:
orderInfo( (Product)hightop);
The above statement would accomplish the same goal and is often more clear inasmuch as it shows that orderInfo() accepts a Product, not a Shoe as its argument.
end note
While in this simplistic example, it is not necessary to use the Product type as our argument. However, its utility becomes apparent when we have multiple classes, each of which implements the same interface. For example, consider a more elaborate Store class with several items, all of which implemented the Product interface-such as in listing 11.7. While it would be necessary to create a different getInfo() method for each item class, we could retain the same orderInfo() method inasmuch as each class was guaranteed to have a MAKER and PHONE field as well as a getPrice(int) method.
Listing 11.7 Using an Interface as a Type to deal with Several Classes
interface Product {
String MAKER = "My Corp";
static final String PHONE = "555-123-4567";
public int getPrice(int id);
public void showName();
}
class Book implements Product {
public int getPrice(int id) {
if (id == 1)
return(20);
else
return(30);
}
public void showName() {
System.out.println("I'm a book!");
}
}
class Shoe implements Product {
public int getPrice(int id) {
if (id == 1)
return(5);
else
return(10);
}
public void showName() {
System.out.println("I'm a shoe!");
}
}
class store {
static Shoe hightop;
static Book using_java;
public static void init() {
hightop = new Shoe();
using_java = new Book();
}
public static void main(String argv[]) {
init();
orderInfo(hightop);
orderInfo(using_java);
}
public static void orderInfo(Product item) {
item.showName();
System.out.println("To order from " +item.MAKER + " call " + item.PHONE + ".");
System.out.println("Each item costs " + item.getPrice(1));
}
}
Output:
C:\dev>\jdk\java\bin\java Store
I'm a shoe!
To order from My Corp call 555-123-4567.
Each item costs 5
I'm a book!
To order from My Corp call 555-123-4567.
Each item costs 20
While an interface contains no implementation code, it is nevertheless possible to create a reference to an interface. Much like pointers in C, simply attempting to invoke a method on a instance of an interface will create a NullPointer exception during execution. What then is purpose of creating such a reference?
As stated earlier, it is possible to create a NullPointer exception when dealing with references to objects. The idea behind the following example is valid. However, we cannot attempt to use the reference until after we have assigned it to an object.
public interface Helper {
public int performOp(int id);
}
public class User {
static Helper inst;
public static void main(String args[]) {
inst.getPrice(6);
}
}
The above code will compile. However, examine the output:
java.lang.NullPointerException
at User.main(user.java:3)
To remedy this problem, we must (as done in listing 11.8) insert at least one more line, assigning the reference to an object that implements the Helper interface
The usefulness of a instance-type refrence variable comes in the fact that you may assign it to an instance of a class that implements the interface. As seen in Listing 11.8 by doing so, we are able to access those methods and fields declared in the interface inasmuch as we are guaranteed that they will be present in the class.
Listing 11.8 Using an Interface as a Variable Type
class InventoryTracker {
static Product commodity;
public InventoryTracker(Product item) {
commodity = item;
}
public static void orderInfo() {
System.out.println("To order from " + commodity.MAKER + " call "
[ic:ccc]+ item.PHONE + ".");
System.out.println("Each item costs $" + commodity.getPrice(1));
}
}
In the above example, the InventoryTracker constructor can be called using any class that implements the Product interface as the parameter. Regardless of the specific class, knowing that it implements the Product interface enables us to create a reference to the object. Since we know that the object must contain a getPrice(int) method and a MAKER and PHONE field, we are therefore able to create an orderInfo() method without even knowing what type of object was passed to the constructor method.
For technical support for our books and software contact support@mcp.com
Copyright ©1996, Que Corporation