Abstraction

Abstraction is a very important element of object oriented software development and is used in the design phase to find a suitable hierarchy for a set of classes.

Booch describes abstraction in the following way:

As the definition says, abstractions are "relative to the perspective of the viewer", what means that it depends a lot on the problem domain for which a class structure shall be created.

The search for abstractions starts after the objects of the problem domain have been found in the analysis phase. What follows is the most difficult and critical part of the development process, because the design of the abstraction levels determines the quality of the whole system.

Example:

Suppose, the result of the analysis phase were the following objects:

» sports car

» mountain bike

» motorcycle

» tandem

» school bus

» pickup

» Ferrari

» truck

» Lotus

Obviously, the objects represent different kinds of vehicles. By realizing that fact, we have found our first abstraction and will take a class "vehicles" as the base class of our hierarchy.

A first attempt in building a hierarchy may look like:

What can be said about this hierarchy is: "Don't try this at home!". Although it contains all objects and therefore it's "correct", it is not very intelligent. An evident violation of the abstraction principle is, for example, that a "sports car" can be found on the same level as a "Ferrari" and a "Lotus". This must be wrong, because they both are kinds of a "sports car".

So we change our hierarchy to the following:

Now we have got a more structured hierarchy with the subclasses "bikes", "sports cars" and "transporters". But they are still too specific. For instance, if a new object "Rolls Royce" is to be added to the hierarchy, where should it be inserted, for it is no sports car?

We rearrange our structure by introducing a new class "cars":

Now there are four levels of abstraction. The new class "cars" may contain the properties that are common to all of its subclasses. But there is still something wrong with our sports cars and limousines. As you can see, they are arranged on the same abstraction level as, for example, a "truck". But a truck is a more abstract thing than a Ferrari or a Rolls Royce.

We try to improve our hierarchy by doing another abstraction:

The fifth abstraction level had been created and our class hierarchy is now much more structured than it was at our first attempt, but is still far from being finished.

This was an example of the abstractioning process that should only demonstrate, how a class hierarchy can be built up and which thoughts have to be made.

The next sections consist of my class hierarchy for neural networks.

Because neural nets are themselves abstract things, the design process was, literally, an "abstraction of abstractions" and, unlike the previous example, took me a few more attempts to get any results.