Abstraction

"An abstraction denotes the essential characteristics of an
object that distinguish it from all other kinds of object and thus
provide crisply defined conceptual boundaries, relative to the
perspective of the viewer."

-- [Booch, 1991]



"[A] simplified description, or specification, of a system that
emphasizes some of the system's details or properties while
suppressing others. A good abstraction is one that emphasizes
details that are significant to the reader or user and suppress
details that are, at least for the moment, immaterial or
diversionary."

-- [Shaw, 1984]


Abstraction, as a process, denotes the extracting of the essential
details aboutan item, or a group of items,while ignoring the
inessential details.

Abstraction, as an entity,
denotes a model, a view, or some other focused representation for
an actual item. Abstraction is most often used as a complexity
mastering technique.


Abstraction refers to the act of representing essential features
without including the background details or explanations.
Classes use the concept of abstraction and are defined as a
list of abstract attributes.

Example:

An electrician and an interior decorator will look at the same building each in two different ways. The decorator will probably view the building primarily as a series of rooms. However, the electrician will view it as a series of walls and floors. Walls are in both their views, but serve a different purpose, have a different priority, and relate in different ways.

Thus, the "abstraction" used by the decorator may be rooms which are composed/comprised of walls and floors/ceilings. But the electrician's view may have the walls be the primary abstraction, with room information incidental, perhaps only to locate the proper wall when walking around.

Further, in the electrician's view, walls are a complex 3D structure with their own little world inside, while the interior decorator may view them mostly as 2D flat panels. Both have walls in their mental abstractions, but view and relate them differently.

Object Oriented Typing

The concept of type is more or less important in a language, depending on whether the language is strongly or weakly (or not at all) typed.

In strongly typed languages, the compiler prevents you from mixing different kinds of data together. This is limiting, but can be very helpful when you want to avoid putting a string, say, into the floating point value for the altitude of an airplane’s automatic pilot.

In OO languuages, type is a synonym for class, at least as a first cut. In fact, class and type are quite distinct. A more nuanced understanding of type is one of the things that distinguishes a shallow from a deep understanding of OO design and programming.

Type defines the properties and behaviors shared by all objects of the same type (class).

OO languages can run the range of un-typed, weakly typed, or strongly typed.

The advantage of strongly typed languages is that the compiler can detect when an object is being sent a message to which it does not respond. This can prevent run-time errors. The other advantages of strong typing are:

• earlier detection of errors speeds development
• better optimized code from compiler
• no run-time penalty for determining type

The disadvantages of strong typing are:

• loss of some flexibility
• more difficult to define collections of heterogenous objects

C++ maintains strong class typing. An object may only be sent a message containing a method that is defined in the object’s class, or in any of the classes that this object inherits from. The compiler checks that you obey this.
Objective C support strong typing, but it also allows for weak typing. A special type, id, can be used for object handles. An id can be a handle to any class of object, thus it has no typing information, and the compiler can’t check if you are sending proper messages. This is done instead at run-time.

Program Execution

The topology of a structure program is inherently different than the topology of an OO program. Modules are nested into a calling tree, as shown below:



By contrast, the topology of an OO program is inherently less ordered. Objects cluster together by those which communicate most frequently. Inter-cluster messages exist, but are less common than intra-cluster messages. Notice how much like a computer network this topology looks.