Re: What is meant by abstraction in object oriented analysis ?

"Abstraction is the elimination of the irrelevant and the amplification of 
the essential," according to Robert C. Martin in "Designing Object-Oriented 
C++ Applications Using the Booch Method," ISBN 0-13-203837-4.

OK, so what does that mean? I like to think of it as the black box effect. 
The idea behind abstraction is to create a layer between an object or 
process and the user of that object or process. Everything that is important 
to the user is visible, but everything that is not--including the processes 
used to carry out tasks--is hidden. The user of the object treats it as a 
black box.

Martin uses the example of a car, which is a particularly good one. To the 
driver of a car, the car is a steering wheel, gas peddle, brake, and either 
an automatic or manual transmission. While it might be interesting, 
everything else is largely irrelevant to the driver of a car. It doesn’t 
matter what the process of locomotion is, for example. It could be a gas 
engine, diesel engine, electric motor, or a bunch of squirrels on a 
treadmill. The driver should not have to care. Well, at least until it comes 
time to put in gas. Squirrels prefer walnuts!

One of the more ideal examples in the world of programming is a drawing 
program that draws shapes, like AutoCAD. Taking a simple example, let’s say 
we have a program that can draw circles and squares. To the program at 
large, these are the same things. Each has a color and an enclosing 
rectangle. Each has some method to save itself to disk, and some method to 
read itself from disk. Each has a mechanism for creating a new object given 
a point and temporary control of the mouse. The detail about whether the 
object is a circle or square is not important to the part of the program 
that redraws the page, loads and saves files, or even the part that 
manipulates mouse commands.

Using Java, the two objects might have an interface like this one:


public class Circle implements CadThing {
	
	<<>>
	
}

public class Square implements CadThing {

   <<>>
	
}

public interface CadThing {

	public void SetColor (Color c);
	
	public Rectangle GetRectangle ();
	
	public void WriteToDisk ();
	
	public CadThing ReadFromDisk ();
	
	public Draw ();
	
	public Create (int mouseX, int mouseY);

}


I’m sweeping a few details under the rug and ignoring some very useful 
features and standard objects from Java to keep this simple, but the idea 
should be clear. To the main program, each of these graphic elements is a 
different kind of the same thing, a CadThing, and each can be treated in 
exactly the same way. In fact, from the standpoint of the rest of the 
program, the only difference between the circle and square is the kind of 
object it instantiates when the user begins to draw a new object. Even that 
is probably abstracted, with all of the details being handled by a tool 
palette.

One of the powerful concepts behind abstraction is this ability to hide all 
of these details so the main program is simpler to design, write, and 
maintain. Another is the ability to reuse software components in other 
applications. That may not seem too obvious from this example, since it’s 
unlikely we’ll need to move CadThing to anything but another CAD program, 
but the idea shines through if you think about Color, one of two Java 
objects I couldn’t resist using. Color has methods like brighter() and 
darker() that return modifications of the color. That could be useful in a 
CAD program or a paint program, to name just two. Once the idea of color is 
abstracted into an object, we can take it from program to program, cutting 
development and debug time.

A third advantage of abstraction is the ability to add to a program with 
little or no change outside the area of interest. If we want to add 
triangles, for example, we can do so without modifying the main program at 
all. In fact, other than creating a new class for Triangle, the only thing 
we have to do is add a triangle to the tool palette and change the method in 
the tool palette that declares a new object so it can declare triangles, 
too.

A fourth benefit is that abstraction hides the implementation from the rest 
of the program. We might start with a clumsy trigonometry based circle 
drawing algorithm, for example, either through ignorance or expedience. 
Later, when we switch to a better method, the rest of the program literally 
has no idea. In some languages it does not even need to be recompiled.

Abstraction is a pretty common concept, and is covered in most books on 
object oriented programming. Martin’s book is a good one, but certainly not 
the only book around.

You can find more examples of abstraction, often in complete, working 
programs in any book on object oriented programming.

Mike Westerfield
Byte Works, Inc.