Abstract classes and interfaces practicum

Move from theory to practice on when to employ abstract classes vs. interfaces

By Tony Sintes, JavaWorld.com, 08/31/01

eaders have returned quite a bit of feedback concerning, "Abstract Classes Vs. Interfaces" from April 2001.

A recurring request asks to see a complete example of using interfaces and abstract classes. Based on the feedback, the original answer proved a bit too theoretical, so in this follow-up Java Q&A, I will bring the discussion down to earth by presenting a framework that employs both interfaces and abstract classes.

When dealing with network communication, you will find that communication is often accomplished through the exchange of key/value pairs. Both HTTP POST and HTTP GET employ key/value pair communication. Key/value pair communication is also the mechanism of choice for communicating with EAI servers such as WebMethods. You even see key/value pairs when you use Java properties. Key/value pairs pop up everywhere.

Key/value pair communication's popularity results from its simple mechanism to assign meaning to a data value. While it is simple, each protocol has its own way of putting the data pairs over the wire. If you want to communicate with a Web server, you use a URLConnection and talk HTTP with the server. Other types of communication will require you to use some other component. For this Q&A , I demonstrate how you can use interfaces and abstract classes in order to define a framework that can work with any server that expects key/value pair messages.

You can make two abstractions about key/value communication. First, the key/value pairs you send to a listener together make up a Message. Second, messages are sent to the server over some sort of protocol. Abstractly, you can call a protocol a MessageBus. So, for example, when communicating with a Web server, you send messages over an HTTP MessageBus.

Both the message you send and the mechanism that sends the message may change often, or at least from program to program. When you know that something will change often, it is a good candidate for an interface.

Let's consider each interface our messaging framework needs.

MessageBus

In the code below you see that a MessageBus knows how to send a 2-dimensional array of key/value pairs to some listener. Notice that the interface doesn't say how the values will be sent or to whom. Instead, those details are left to the class that implements the interface:

public interface MessageBus {
    public String sendMessage( String [][] values ) throws BusException;
}

The use of an interface here is very powerful. You can have an implementation that uses URLConnections to talk HTTP. Another implementation might use a proprietary socket protocol. Yet another may just log the values to a flat file or database.

In any case, the interface allows you to create many different implementations. More so, if you program to the interface instead of some specific implementation, polymorphism allows you to freely swap in any implementation into your program.

So, for example, you can swap out an HTTP MessageBus implementation for a logging implementation if you wish to debug your application. Such an approach allows you to change the way your program works without requiring all kinds of changes to the original application. Whenever your program needs to support a new type of communication, you can simply create a new MessageBus implementation and you're done.