Frameworks, Libraries, and Abstraction

Abstraction is sometimes a game of guessing the future. You try to design a class, or set of classes, that will hopefully be in use for several years . How can you predict today what can be useful tomorrow? The answer is, of course, experience. As you develop more experience in working with classes, you start to see how the OO paradigm works. Also, you start to appreciate the tools it provides.

There are times when a decision is made that might seem to defeat the purpose of a single class. These are usually the times when a single class isn t really the goal, but really an entire class library or framework is the important part. Put another way, you may find yourself writing a class that requires you to implement certain abstract methods from a base class that simply might not make sense.

If you look at it on the basis of just your class, it might seem silly. But, if you consider the larger picture of the framework or library, it will start to make sense. Let s take a look at a perfectly good example in Java: the String class and its toString method.

Java has a String class, which contains, of course, a string. Now, in this String class is a method called toString . And what does toString give us? A string that represents our data. How silly is that? A String class that has a method to return a string variable.

Turns out, it s really not silly at all, but quit ingenious if we look at the Java Library. See, toString isn t just part of the String class, it s part of the Object class from which all Java classes are derived. This means that toString is really defined for all Java objects. This is exceptionally cool when we consider that for debugging purposes we should be able to display the contents of any Java object using the following code:

 System.out.print( AnyObject.toString() ); ! 

We are bypassing a few of the details of implementation, and not showing any actual code, in order to make a point: The needs of the many outweigh the needs of the one. Or, it is often better to design a set of classes with an overall usefulness that a small number of classes might not seem to benefit from. The truth is, we would probably figure out by looking closer at them that they probably all do benefit.