Smarter Java development

Use interfaces to effectively enforce development contracts while maintaining loose coupling of code

By Michael Cymerman, JavaWorld.com, 08/01/99

By incorporating interfaces into your next project, you will noticebenefits throughout the lifecycle of your development effort. The technique of coding to interfaces rather than objects will improve the efficiency of the development team by:

• Allowing the development team to quickly establish the interactions among the necessary objects, without forcing the early definition of the supporting objects
• Enabling developers to concentrate on their development tasks with the knowledge that integration has already been taken into account
• Providing flexibility so that new implementations of the interfaces can be added into the existing system without major code modification
• Enforcing the contracts agreed upon by members of the development team to ensure that all objects are interacting as designed

An overview

Because object-oriented development efforts involve the interactions of objects, it is essential to develop and enforce strong contracts between those objects. The technique of coding to interfaces involves using interfaces, rather than objects, as the primary method of communication.

This article will introduce the user to the concept of coding to interfaces through a simple example. A detailed example will follow, helping demonstrate the value of this scheme in a larger system requiring multiple developers. Before we get to the sample code, however, let's look at the benefits of coding to interfaces.

Why code to interfaces?

The Java interface is a development contract. It ensures that a particular object satisfies a given set of methods. Interfaces are used throughout the Java API to specify the necessary functionality for object interaction. Examples of interface use are callback mechanisms (Event Listeners), patterns (Observer), and specifications (Runnable, Serializable).

Coding to interfaces is a technique by which developers can expose certain methods of an object to other objects in the system. The developers who receive implementations of these interfaces have the ability to code to the interface in place of coding to the object itself. In other words, the developers would write code that did not interact directly with an object as such, but rather with the implementation of that object's interface.

Another reason to code to interfaces rather than to objects is that it provides higher efficiency in the various phases of a system's lifecycle:

• Design: the methods of an object can be quickly specified and published to all affected developers
• Development: the Java compiler guarantees that all methods of the interface are implemented with the correct signature and that all changes to the interface are immediately visible to other developers
• Integration: there is the ability to quickly connect classes or subsystems together, due to their well-established interfaces
• Testing: interfaces help isolate bugs because they limit the scope of a possible logic error to a given subset of methods

There is some overhead associated with this development technique, due to the required code infrastructure. This infrastructure includes both interfaces for the interactions between objects and invocation code to create implementations of interfaces. This overhead is insignificant when compared to the ease and benefit of using interfaces as described.

Basic example

To further explain the concept of coding to interfaces, I have created a simple example. While this example is clearly trivial, it demonstrates some of the benefits mentioned above.

Consider the simple example of a class Car that implements interface Vehicle. Interface Vehicle has a single method called start(). Class Car will implement the interface by providing a start() method. Other functionality in the Car class has been left out for the sake of clarity.

interface Vehicle {
        // All  vehicle implementations must implement the start method
   public void start();
}
class Car implements Vehicle{
        //  Required to implement Vehicle
   public void start(){ ... }
}

Having laid the foundations of the Car object, we can create another object called Valet. It is the Valet's job to start the Car and bring it to the restaurant patron. The Valet object can be written without interfaces, as follows:

class Valet {
   public Car getCar( Car c){ ... }
}

The Valet object has a method called getCar that returns a Car object. This code example satisfies the functional requirements of the system, but it forever links the Valet object with that of the Car. In this situation, the two objects are said to be tightly coupled. The Valet object requires knowledge of the Car object and has access to all public methods and variables contained within that object. It is best to avoid such tight coupling of code because it increases dependencies and reduces flexibility.

To code the Valet object using interfaces, the following implementation could be used:

class Valet{
   public Vehicle getVehicle( Vehicle c) {  ...  }
}

While the code changes are fairly minor -- changing the references from Car to Vehicle -- the effects on the development cycle are considerable. Using the second implementation, the Valet has knowledge only of the methods and variables defined in the Vehicle interface. Any other public methods and data contained in the specific implementation of the Vehicle interface are hidden from the user of the Vehicle object.

This simple code change has ensured the proper concealment of information and implementation from other objects, and has therefore eliminated the possibility that developers will use undesirable methods.

Creating the interface object

The last issue to discuss with respect to this development technique is the creation of the interface objects. While it is possible to create a new instance of a class using the new operator, it is not possible to directly create an instance of an interface. In order to create an interface implementation, you must instantiate the object and cast it to the desired interface. Therefore, the developer who owns the object code can be responsible for both creating the instance of the object and performing the casting.

Free Download - 5 Minute Product Review. When slow equals Off: Manage the complexity of Web applications - Symphoniq

Free Download - 5 Minute Product Review. Realize the benefits of real user monitoring in less than an hour. - Symphoniq