Incremental Java
Abstraction

What is Abstraction?

Ever look at a road map? How accurate is it? Does it tell you where stores or located? Where the houses are? Which roads are two lanes, which are one way? Does it tell you if there's construction work being done? Does it tell special hours when the roads are closed? Does it tell you who lives where?

A map is an abstraction of the world. It removes details that you don't care about, and keeps the important details. It is one way to view the world. We use maps because we care about roads.

A better example, to me, of abstraction is the remote control. In this case, I see abstraction as a way to view the world. The remote control designer is trying to give the user, i.e., the TV viewer, a way of looking at the world, in this case, the TV set.

A remote control has buttons to select the channel, set the volume, turn the power on and off, perhaps adjust the picture and turn on DVD players, etc.

But, do you know how a remote control works? I don't mean, do you know how to use a remote control. I mean, do you know how it works? How does the electronics do what it does? And does it really matter?

Someone designed this remote control so you wouldn't care whether an infrared signal or a radio signal or a pair of hamsters did the work. They tell you that this button increases the volume, and you don't worry about how it does this magical feat. Some engineers figured it out, and you don't have to worry about it.

Interface vs. Implementation

An interface is something the user uses. For example, the buttons on the remote control and what they do are the interface for the remote control. The user of the remote control only has to understand the interface and how it behaves.

The remote control designer has to worry about how to get the interface to do what it's supposed to do. When the user pushes the up volume, the designer must think about the electronics needed to make that happen. This is called the implementation. The implementation is often far more complicated than the interface.

The implementation is usually hidden from the user. There are two reasons for this. First, the user doesn't need to see complexity. It distracts from their view of the world. They don't want to think about the physics and math needed to understand how a remote control does what it does.

Second, and less obvious, it allows the implementation to change without users having to worry about it. Suppose you ask several groups of engineers to take a common remote control and get it to work. Undoubtedly, each group comes up with a different solution. Each of the remote controls designed by each group behaves the same (at least, they should, assuming the interface and specification given to the engineers is accurate enough) at least from the user's perspective, but the actual electronics might be quite different.

We're going to think about objects in just this way. Objects have things like buttons. They change the object or get information from the object. However, the actual details of how the object changes or how it computes its information is hidden from you.

As a programmer, you are going to serve two roles. You are going to be an object user as well as a class designer. A class designer handles the implementation and designs the interface for an object user to use. The object user doesn't think about how the object does what it does, but just uses it, as described.