C++?? 8
3rd Edition © Ian Joyner 1996
worthless in itself. But the Silver Bullet rationale is
not a valid rationale against adopting better
programming languages, tools and environments;
unfortunately, Brooks’ article has been misused.
Another example of consistency checking comes
from the user interface world. Instead of correcting a
user after an erroneous action, a good user interface
will not offer the action as a possibility in the first
place. It is cheaper to avoid error than to fix it. Most
people drive their cars with this principle in mind:
smash repair is time consuming and expensive.
Program development is a dynamic process;
program descriptions are constantly modified during
development. Modifications often lead to
inconsistencies and error. Consistency checks help
prevent such ‘bugs’, which can ‘creep’ into a
previously working system. These checks help
verify that as a program is modified, previous
decisions and work are not invalidated.
It is interesting to consider how much checking
could be integrated in an editor. The focus of many
current generation editors is text. What happens if
we change this focus from text to program
components? Such editors might check not only
syntax, but semantics. Signalling potential errors
earlier and interactively will shorten development
times, alerting programmers to problems, rather than
wasting hours on changes which later have to be
undone. Future languages should be defined very
cleanly in order to enable such editor technology.
2.8 Encapsulation
There is much confusion about encapsulation,
mostly arising from C++ equating encapsulation
with data hiding. The Macquarie dictionary defines
the verb to encapsulate as “to enclose in or as in a
capsule.” The object-oriented meaning of
encapsulation is to enclose related data, routines and
definitions in a class capsule. This does not
necessarily mean hiding.
Implementation hiding is an orthogonal concept
which is possible because of encapsulation. Both
data and routines in a class are classified according
to their role in the class as interface or
implementation.
To put this another way: first you encapsulate
information and operations together in a class, then
you decide what is visible, and what is hidden
because it is implementation detail. Most often only
the interface routines and data should appear at
design time, the implementation details appearing
later.
Encapsulation provides the means to separate
the abstract interface of a class from its
implementation: the interface is the visible surface
of the capsule; the implementation is hidden in the
capsule. The interface describes the essential
characteristics of objects of the class which are
visible to the exterior world. Like routines, data in a
class can also be divided into characteristic interface
data which should be visible, and implementation
data which should be hidden. Interface data are any
characteristics which might be of interest to the
outside world. For example when buying a car, the
purchaser might want to know data such as the
engine capacity and horse-power, etc. However, the
fact that it took John Engineer six days to design the
engine block is of no interest.
Implementation hiding means that data can only
be manipulated, that is updated, within the class, but
it does not mean hiding interface data. If the data
were hidden, you could never read it, in which case,
classes would perform no useful function as you
could only put data into them, but never get
information out.
In order to provide implementation hiding in
C++ you should access your data through C
functions. This is known as data hiding in C++. It is
not the data that is actually being hidden, but the
access mechanism to the data. The access
mechanism is the implementation detail that you are
hiding. C++ has visible differences between the
access mechanisms of constants, variables and
functions. There is even a typographic convention of
upper case constant names, which makes the
differences between constants and variables visible.
The fact that an item is implemented as a constant
should also be hidden. Most non-C languages
provide uniform functional access to constants,
variables and value returning routines. In the case of
variables, functional access means they can be read
from the outside, but not updated. An important
principle is that updates are centralised within the
class.
Above I indicated that encapsulation was
grouping operations and information together.
Where do functions fit into this? The wrong answer
is that functions are operations. Functions are
actually part of the information, as a function returns
information derived from an object’s data to the
outside world.
This theme and its adverse consequences, that
place the burden of encapsulation on the
programmer rather than being transparent, recur
throughout this critique.
2.9 Safety and Courtesy Concerns
This critique makes two general types of criticism
about ‘safety’ concerns and ‘courtesy’ concerns.
These themes recur throughout this critique, as C
and C++ have flaws that often compromise them.
Safety concerns affect the external perception of the
quality of the program; failure to meet them results
in unfulfilled requirements, unsatisfied customers
and program failures.
Courtesy concerns affect the internal view of
the quality of a program in the development and
maintenance process. Courtesy concerns are usually
stylistic and syntactic, whereas safety concerns are
semantic. The two often go together. It is a courtesy
concern for an airline to keep its fleet clean and well