Object-oriented (and object-based) programming propagates a slightly different
approach to programming problems than the strategy usually used in bf(C)
programs. In bf(C) programming problems are usually solved using a
`i(procedural approach)': a problem is decomposed into subproblems and this
process is repeated until the subtasks can be coded. Thus a conglomerate of
functions is created, communicating through arguments and variables, global or
local (or tt(static)).

In contrast (or maybe better: in addition) to this, an object-based approach
identifies the bf(keywords) used in a problem statement. These keywords are
then depicted in a diagram where arrows are drawn between those keywords to
depict an internal hierarchy. The keywords become the objects in the
implementation and the hierarchy defines the relationship between these
objects. The term object is used here to describe a limited, well-defined
structure, containing all information about an entity: data types and
functions to manipulate the data. As an example of an
  i(object oriented approach), an illustration follows:
    quote(
    The employees and owner of a car dealer and auto garage company are paid
    as follows. First, mechanics who work in the garage are paid a certain sum
    each month. Second, the owner of the company receives a fixed amount each
    month. Third, there are car salesmen who work in the showroom and receive
    their salary each month plus a bonus per sold car. Finally, the company
    employs second-hand car purchasers who travel around; these employees
    receive their monthly salary, a bonus per bought car, and a restitution of
    their travel expenses.
    )
    When representing the above salary administration, the keywords could be
mechanics, owner, salesmen and purchasers. The properties of such units are: a
monthly salary, sometimes a bonus per purchase or sale, and sometimes
restitution of travel expenses. When analyzing the problem in this manner we
arrive at the following representation:
    itemization(
    it() The owner and the mechanics can be represented by identical types,
receiving a given salary per month. The relevant information for such a type
would be the monthly amount. In addition this object could contain data as the
name, address and social security number.
    it() Car salesmen who work in the showroom can be represented as the same
type as above but with some em(extra) functionality: the number of
transactions (sales) and the bonus per transaction.

    In the hierarchy of objects we would define the dependency between the
first two objects by letting the car salesmen be `derived' from
the owner and mechanics.
    it() Finally, there are the second-hand car purchasers. These share the
functionality of the salesmen except for travel expenses. The additional
functionality would therefore consist of the expenses made and this type would
be derived from the salesmen.
    )
    The hierarchy of the identified objects are further illustrated in
fig(objects).
    figure(intro/objects)(Hierarchy of objects in the salary administration.)
    (objects)

The overall process in the definition of a hierarchy such as the above starts
with the description of the most simple type. Traditionally (and still
encountered with some popular object oriented languages) more complex types
are thereupon derived from the basic type, with each derived type adding some
new functionality. From these derived types, more complex types can again be
derived em(ad infinitum), until a representation of the entire problem can be
made. 

Over the years this approach has become less popular in bf(C++) as it
typically results in very tight emi(coupling) among those types, which in
turns em(reduces) rather than enhances the understanding, maintainability and
testability of complex programs. The term em(coupling) refers to the degree of
independence between software components: tight coupling means a strong
dependency, which is frowned upon in bf(C++). In bf(C++) object oriented
programs more and more favor small, easy to understand hierarchies, limited
coupling and a developmental process where hi(design pattern)em(design
patterns) (cf. em(Gamma et al.)  (1995)) play a central role.

In bf(C++) hi(class) em(classes) are frequently used to define the
characteristics of em(objects). Classes contain the necessary functionality to
do useful things. Classes generally do not offer all their functionality (and
typically em(none) of their data) to objects of other classes. As we will see,
classes tend to em(hide) their properties in such a way that they are not
directly modifiable by the outside world. Instead, dedicated functions are
used to reach or modify the properties of objects. Thus class-type objects are
able to uphold their own integrity. The core concept here is em(encapsulation)
of which em(data hiding) is just an example. These concepts are further
elaborated in chapter ref(Classes).
