October 21, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Objects and Interfaces

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

Abstract Hierarchies

For example, consider the model where you want to create subclasses of the RightHandBatter class, say a class called GoodRightHandBatter. In this case, you could implement the swing( ) method in the subclass. Note that in Figure 4, both the Batter and the RighHandBatter classes are abstract—only the final class in the hierarchy, GoodRightHandBatter is considered concrete, which means that you can instantiate it.

Figure 4: Abstract Hierarchy

The error message states that "RightHandBatter is not abstract." This is because it is not defined as abstract. If you wanted to make RightHandBatter abstract, the code would look like this:

public abstract class RightHandBatter implements Batter {

}

The error message also states that "RightHandBatter does not override abstract method swing( ) is Batter". This is the important issue in this example. The compiler is catching the fact that RightHandBatter is not satisfying the contract because it is not overriding the abstract method swing( ). Herein lies the power of the interface. By designing the appropriate interfaces and then requiring their use, software developers have a powerful tool.

To remedy the problem in the example above, a simple redesign is in order. The redesign will require the following code change as seen in Listing 6.

Listing 6: RightHandBatter.java

public class RightHandBatter implements Batter {

   public void swing() {

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

   }

}

Now that the swing( ) method has been provided, the code for the RightHandBatter class will compile cleanly. The same approach must be followed for the LeftHandBatter class.

Listing 7: LeftHandBatter.java

public class LefttHandBatter implements Batter {

   public void swing( ) {

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

   }

}

At this point, you can standardize the way that you have batters swing by simply using a swing( ) method regardless of what type of batter you have at the plate.

Listing 8: TestBatter.java

class TestBatter{

   public static void main(String[] args){

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

      lefty.swing( );
      righty.swing( );

   }
}

No matter who the batter is, when you want the batter to swing, you only have to say "swing". This can cut down on any number of errors; however, perhaps the greatest power of the object-oriented interface is the increased usability. Basically, systems with well designed object-oriented interfaces are much easier to use and have less maintenance cost. To illustrate, you can try to enhance this system.

You can create a third type of batter called switchHitter, as seen in Listing 9. The class diagram representing the updated system is found in Figure 5.

Listing 9: SwitchHitter.java

public class SwitchHitter implements Batter {

   public void swing() {

      System.out.println("Switch Hitter Swing");

   }

}

Because the programmer implementing this class is required to implement the interface Batter, the swing( ) method is required. Thus, when the application uses the new SwitchHitter class, all the application needs to know is: If SwitchHitter is a true Batter, all I have to do is say "swing" and the SwitchHitter will swing, as seen in Listing 10.

Listing 10: TestBatter.java

class TestBatter{

   public static void main(String[] args){

      LeftHandBatter lefty      = new LeftHandBatter();
      RightHandBatter righty    = new RightHandBatter();
      SwitchHitter switchHitter = new SwitchHitter ();

      lefty.swing();
      righty.swing();
      switchHitter.swing();

   }
}

Figure 5: Batter Hierarchy

With the Batter interface in place, you can add as many different types of Batters as you like. And, no matter what the type of Batter is or does, you will know that it will have a swing( ) method.

Interfaces versus implementation

Although the object-oriented interface requires that a prescribed contract be followed, there is no way to enforce the code implementation of the contract.

For example, consider the code in Listing 11. This is a simple example. There are no object-oriented interfaces; however, there is a method defined as add( ). The danger with any method, whether it is part of an interface specification or not, is that the implementation within the method body (the actual code) is at the discretion of the programmer.

Listing 11: TestBatter.java

class TestInterface {

   public static void main(String[] args){

      int value = 0;

      value = add(5, 6);

      System.out.println("value = " + value);

   }

   public static int add (int num1, int num2) {

      int num = num1 - num2;

      return num;
   }
}

As can be seen in the example in Listing 11, a programmer may well follow a method specification, in this case add( ); yet the implementation may be at odds with the interface. In this case, the understandable expectation is that the add( ) method will return the sum of the parameters, not the difference, as this code apparently does. There is not a compiler mechanism that can enforce this. In short, using object-oriented interfaces is a great way to enforce the user interfaces, but they will not control the implementation.

Conclusion

When creating an interface, all of the methods must be abstract. There is no actual implementation code in an object-oriented interface. However, there are times when you want to design a class that has both abstract and concrete methods.

In some languages, like C++, the same mechanism is used to create interfaces, which contain only abstract methods, and abstract classes, which contain both abstract and concrete methods.

In the next article, you will explore the differences between abstract classes and interfaces.

References

  • www.sun.com
  • Just Java 2, 6th Edition. Peter van der Linden. 2004, Sun Microsystems.

About the Author

Matt Weisfeld is a faculty member at Cuyahoga Community College (Tri-C) in Cleveland, Ohio. Matt is a member of the Information Technology department, teaching programming languages such as C++, Java, C#, and .NET as well as various Web technologies. Prior to joining Tri-C, Matt spent 20 years in the information technology industry gaining experience in software development, project management, business development, corporate training, and part-time teaching. Matt holds an MS in computer science and an MBA in project management. Besides The Object-Oriented Thought Process, which is now in its second edition, Matt has published two other computer books, and more than a dozen articles in magazines and journals such as Dr. Dobb's Journal, The C/C++ Users Journal, Software Development Magazine, Java Report, and the international journal Project Management. Matt has presented at conferences throughout the United States and Canada.





Page 3 of 3



Comment and Contribute

 


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

 

 


Sitemap | Contact Us

Rocket Fuel