24 SECTION I CONCEPTS
at one time, but through abstraction, we use chunks of information with increas-
ingly greater semantic content. This is especially true if we take an object-oriented
view of the world because objects, as abstractions of entities in the real world,
represent a particularly dense and cohesive clustering of information. Chapter 2
examines the meaning of abstraction in much greater detail.
The Role of Hierarchy
Another way to increase the semantic content of individual chunks of information
is by explicitly recognizing the class and object hierarchies within a complex soft-
ware system. The object structure is important because it illustrates how different
objects collaborate with one another through patterns of interaction that we call
mechanisms. The class structure is equally important because it highlights com-
mon structure and behavior within a system. Thus, rather than study each individ-
ual photosynthesizing cell within a specific plant leaf, it is enough to study one
such cell because we expect that all others will exhibit similar behavior. Although
we treat each instance of a particular kind of object as distinct, we may assume
that it shares the same behavior as all other instances of that same kind of object.
By classifying objects into groups of related abstractions (e.g., kinds of plant cells
versus animal cells), we come to explicitly distinguish the common and distinct
properties of different objects, which further helps us to master their inherent
complexity [37].
Identifying the hierarchies within a complex software system is often not easy
because it requires the discovery of patterns among many objects, each of which
may embody some tremendously complicated behavior. Once we have exposed
these hierarchies, however, the structure of a complex system, and in turn our
understanding of it, becomes vastly simplified. Chapter 3 considers in detail the
nature of class and object hierarchies, and Chapter 4 describes techniques that
facilitate our identification of these patterns.
1.6 On Designing Complex Systems
The practice of every engineering discipline—be it civil, mechanical, chemical,
electrical, or software engineering—involves elements of both science and art. As
Petroski eloquently states, “The conception of a design for a new structure can
involve as much a leap of the imagination and as much a synthesis of experience
and knowledge as any artist is required to bring to his canvas or paper. And once
that design is articulated by the engineer as artist, it must be analyzed by the engi-
neer as scientist in as rigorous an application of the scientific method as any

198 SECTION II METHOD
A template class may not have any instances and may not itself be used as a tem-
plate. A bound class defines a new class distinct from all other concrete classes in
the same family whose actual parameters differ.
Advanced Concepts: Visibility
In Section 5.2, Package Diagrams, we discussed the concept of visibility from the
view of whether the elements contained by a package could be seen outside that
package. A class also provides an enclosing namespace for its contained ele-
ments. Here, we will look at the visibility of class associations, attributes, and
operations.
All interesting object-oriented programming languages provide a clear separation
between the interface and implementation of a class. As we described in Chapter
3, most also permit the developer to specify finer-grained access to the interface
as well. For example, in C++, members may be public (accessible to all clients),
protected (accessible only to subclasses, friends, or the class itself), or private
(accessible only to the class itself or its friends). Also in C++, certain elements
might be a part of a class’s implementation and thus inaccessible even to friends
of the class; this is referred to as implementation visibility.
Figure 5–37 A Template Class and Its Bound Class