5.6.1 Why Object-Oriented Programming?

The term object-oriented has been a catchword gaining more and more importance in recent years [Wien88][Wens91][Tell89][Rumb91][Flor91][Elli90][Dani91][Budd91][Boni91][Betz89]. Rarely, however, there has been a more misinterpreted term in computer science as well. This term has even gained a foothold in areas where object-orientedness in its genuine meaning makes no sense at all.

Looking at the term object detached from its computer-science meaning, we see that it is a very common word used in the real world for any-thing we can see and touch, be it a house, a table or a stone. Mapping this meaning back to the abstract computer-science world, any-thing (i.e. any opaque data set seen as a whole) could be termed an object. But this would be just another term for the programming paradigm of data encapsulation, i.e. grouping data items which belong together into a single aggregate which we then call object.

This is, however, not what object-oriented programming is supposed to be. The object-oriented programming paradigm encompasses the following programming paradigms:

data encapsulation
Like stated above, this is the grouping of semantically interdependent data items (members) into an aggregate (class) seen as a single data item. This is termed class definition in object-oriented languages. Although this feature is available in all procedural third-generation programming languages (like a record in PASCAL or struct in C), an object-oriented language has to extend this paradigm with a

taggedblock storage concept
Each of the different aggregate data types (blocks) can be identified at run-time through a unique identifier (tag) given to and stored in that aggregate type. This enables the dynamic identification of encapsulated data at run-time, which is a big advantage over statically typed languages like C or PASCAL. Although not object-oriented per se, Common LISP's (see [Fran88][Stee90][Wins89]) DEFSTRUCT command implements this concept (there exists a separate object system extension for Common LISP, [Bobr88]).

function encapsulation
Every self-contained idea is consistently coded into a sequence of statements grouped together forming a function (method). While this feature is available in any third generation language, traditional procedural languages do not intrinsically associate a function with an encapsulated data aggregate. In object-oriented languages however, there must be a

data-function association
This association of a method with a class together with the method code makes up the method definition. We can say, the method is defined on or belongs to a specific class.

The association of data sets (i.e. classes) with the corresponding functions working on a particular data set (i.e. methods) is an intrinsic advantage of object-oriented programming languages over traditional procedural languages.

inheritance
The most distinct features of object-oriented programming languages are member inheritance and method inheritance. Member inheritance means that a class inherits all members of its parent class. This vaguely resembles the inclusion of an already declared structure in a new structure declaration in C, although in this case the ``inherited'' members are not opaquely accessible because they are hidden in the included structure declaration, whereas in an object-oriented programming language inherited members are in general indistinguishable from intrinsic class members. Method inheritance is implicitly achieved through declaring the parent of a class, since all (public) methods of the parent class become available to the inheriting class. Again, inherited methods are indistinguishable from intrinsic methods defined on the class. This could be emulated in C through macro-aliasing a new function name to an existing function and applying the function to the included structure as mentioned above.