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 in
vogue with some popular object oriented languages) more complex types are then
derived from the basic set, with each derivation adding a little extra
functionality. From these derived types, more complex types can be derived
em(ad infinitum), until a representation of the entire problem can be
made. Over the years, however, this approach has become less popular in
bf(C++) as it typically results in overly tight emi(coupling), which in turns
em(reduces) rather than enhances the understanding, maintainability and
testability of complex programs. In bf(C++) object oriented program more and
more favors small, easy to understand hierarchies, limited coupling and a
developmental process where emi(design patterns) (cf. em(Gamma et al.)
(1995)) play a central role.

Nonetheless, 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 emi(encapsulation) of which
  emi(data hiding) is just an example. These concepts will be further
explained in chapter ref(Classes).