6.3 Object-Oriented Design | 275specifies a set of responsibilities, which are the actions that its objects support.
Objects collaboratewith each other by sending messages. A message is a request
for an object to carry out one of its responsibilities. The collection of Classes,
Responsibilities, and Collaborations (CRC) works together to solve a problem.
OOD thus leads to programs that are collections of objects. Each object is re-
sponsible for one part of the entire solution, and the objects send messages to one
another in a collaborative manner. Many libraries of prewritten classes are avail-
able, including the standard Java library. In many cases, it is possible to browse
through a library, choose classes you need for a problem, and assemble them to
form a substantial portion of your application. Putting existing pieces together in
this fashion is an excellent example of the building-block approach discussed in
Chapter 1.
Let’s briefly return to the more general topic of problem solving before we look at CRC
cards in depth.
Object-Oriented Problem Solving
As we discuss OOD, keep in mind that there are many different correct solutions to most prob-
lems. The techniques we use may seem imprecise, especially when contrasted with the pre-
cision required by the computer. In fact, the computer merely demands that we express
(code) a particular solution precisely. The process of deciding which particular solution to use
involves the skills of judgment and reasoning. It is our human ability to make choices with-
out having complete information that enables us to solve problems. Different choices nat-
urally lead to different solutions to a problem.
For example, in developing a simulation of an air traffic control system, we might decide
that airplanes and control towers are objects that communicate with each other. Or we might
decide that pilots and controllers are the objects that communicate. This choice affects how
we subsequently view the problem and the responsibilities that we assign to the objects. Either
choice can lead to a working application. We may simply prefer the one with which we are
most familiar (recall the “Look for things that are familiar” strategy from Chapter 1).
Some of our choices lead to designs that are more or less efficient than others. For ex-
ample, keeping a list of names in alphabetical order rather than random order makes it pos-
sible for the computer to find a particular name much faster. However, choosing to leave the
list randomly ordered still produces a valid (but slower) solution.
Other choices affect the amount of work that is required to develop the remainder of a
problem solution. In creating an application for choreographing ballet movements, we might
begin by recognizing the dancers as the important objects and then create a class for each
dancer. In doing so, we discover that all of the dancers have certain common responsibili-
ties. Rather than repeat the definition of those responsibilities for each class of dancer, we
can change our initial choice: we can define a class for a generic dancer that includes all the
common responsibilities and then develop subclasses (the subject of Chapter 7) that add re-
sponsibilities specific to each individual.
Responsibility An action that
an implementation of an object
must be capable of performing
Collaboration An interaction
between objects in which one
object requests that another ob-
ject carry out one of its responsi-
bilities