February 16, 2019
Hot Topics:

Objects and Interfaces

  • October 4, 2006
  • By Matt Weisfeld
  • Send Email »
  • More Articles »

Designing with Object-Oriented Interfaces

Let me start right away with an example. Suppose that you work for a software development company that is writing software to play a baseball game. You will create a class called Batter and this Batter class will have a behavior (method) called swing. There are a number of programmers assigned to work on the project. One programmer is assigned the task to design and implement the LeftHandedBatter class, and one is assigned to design and implement the RightHandedBatter class. If you then send them off to their respective cubes, they may, possibly, come back with the following two class designs in Listing 1 and Listing 2.

Listing 1: RightHandBatter.java

public class RightHandBatter {

   public void rightHandBatterSwing () {

      System.out.println("Righty Swing");



Listing 2: LeftHandBatter.java

public class Lefty {

   public void leftySwing() {

      System.out.println("Lefty Swing");



To use these classes, you create an application called TestBatter that is found in Listing 3.

Listing 3: TestBatter.java

class TestBatter{

   public static void main(String[] args){

      Lefty lefty = new Lefty();
      RightHandBatter righty = new RightHandBatter();



Perhaps you have noticed a fundamental flaw in the management, or lack of management, involved in this project. The flaw is that the way you swing differs depending on the type of batter you are. If you are a right-handed batter, you must use the rightHandBatterSwing( ) method, and if you are a left-handed batter, you must use the leftySwing ( ) method. At first, this may not seem like much of a problem; however, the names of the methods are not necessarily consistent. In fact, the decision on the name of the methods was left totally up to the discretion of the programmers. While this may be a good way to encourage creativity, it is not a very good design decision. Now, explore this problem more closely.

As the project manager for this application, one thing that I want to ensure is that the naming conventions are standard, clearly specified, and enforced. For example, if you were a third programmer on this team with the responsibility to actually use the two batter classes, you might logically assume that when any batter swings the method would be called swing( ). While this may seem reasonable, the two programmers in this case came up with two totally different method names. Even though these differing method names would work in practice, they are not good design for several reasons, including the fact that swing( ) is a much better choice. So, how would a project manager force all the Batter classes to use a method called swing( )?

Abstract Methods

This is where the object-oriented interface comes in. Short of doing code reviews and disciplining programmers who do not follow the programming standards, you can create an interface called Batter. You can create a class diagram representing the design of this interface, simple as it is. This class diagram is found in Figure 2. Note that the class name and the method swing( ) are presented in italics, which signifies that the class and the method are abstract.

Figure 2: Batter Interface

The corresponding code is found in Listing 4.

Listing 4: Batter.java

public interface Batter {

   public void swing();


By itself, this will not directly remedy the inconsistencies; however, as project manager, I now require that all programmers creating any type of Batter class must implement this Batter interface. While there is not much code in Listing 4, it illustrates a very important concept. By creating this interface, the project manager is saying:

To be a valid type of batter class, you must implement the Batter interface that requires you to implement a method called swing( ).

In effect, the Batter interface is a contract that the programmer must follow. The contract states that if you want to be a Batter in this system, you must implement the Batter interface. Abiding by this contract requires that you provide a swing( ) method. The class diagram for the entire Batter system is shown in Figure 3. Note that both the RightHandBatter class and the LeftHandBatter class must implement the swing( ) method.

Figure 3: Batter System

Thus, when the programmer who creates the right hand batter class writes code that does not conform to this model, as seen in Listing 5, you have a problem.

Listing 5: RightHandBatter.java

public class RightHandBatter implements Batter {

   public void rightHandBatterSwing() {

      System.out.println("Righty Swing");



With the Batter interface in place, the programmer who attempts to compile the class in Listing 5 will receive the following compiler error:

C:column27>"C:Program FilesJavajdk1.5.0_06binjavac"
   -Xlint -classpath . RightHandBatter.java

RightHandBatter.java:1: RightHandBatter is not abstract and does
not override abstract method swing() in Batter
public class RightHandBatter implements Batter {
1 error

The error was generated due to the fact that the programmer who designed this class failed to meet the requirements of the contract. The content of the message is informative. The interface Batter contains a single method specification, swing( ). Note that the swing method has no implementation. By this, I mean that there are no curly braces as follows:

public void swing( ){ };

Even though there is no working code between these curly braces, the mere fact that the curly braces are present provides an implementation. It is an empty implementation; however, it is an implementation nonetheless. The code for the interface contains only the method signature and no curly braces.

public void swing( );

This syntax defines the method as abstract. When a method is abstract, this means that any class implementing or inheriting this abstract method must provide the implementation for the abstract method or that class will itself be considered abstract.

Page 2 of 3

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date