Programming and Problem Solving with Java

(^280) | Object-Oriented Software Design and Implementation
ject. Thus we can combine Home, Work, Fax, Pager, and Cell Phone into a Phone number
class. We decide that the electronic address book doesn’t need the special pages that are of-
ten found in a printed address book, so we delete Calendar, Time Zone Map, Owner
Information, and Emergency Numbers.
Of course, the User isn’t part of the application, although its identification does point to
the need for a User interface that we did not originally list. A Work Address is a specific kind
of address that has additional fields, so we can make it a subclass of Address. Company
Names are just strings, so there is no need to distinguish them, but Names have a first, last,
and middle part. Our filtered list of classes now looks like this:
For each of these classes, we create a CRC card. In the case of a Work Address, we list
Address as its Superclass and on the Address card we list Work Address in its Subclasses space.
In doing coursework, you may be asked to work individually rather than in a collabora-
tive team. You can still do your own brainstorming session and filtering. However, we rec-
ommend that you take a break after the brainstorming session and do the filtering once you
have let your initial ideas rest for a while. An idea that seems brilliant in the middle of brain-
storming may lose some of its attraction after a day or even a few hours.

Determining Responsibilities

Initial Responsibilities Once you (or your team) have identified the classes and created CRC cards

for them, go over each card and write down any responsibilities that are obvious. For exam-

ple, a Name class has a responsibility to know its first name, its middle name, and its last

name. We would list these three responsibilities in the left column of its card as shown in

Figure 6.4. In an implementation, they become methods that return the corresponding part

of the name. For many classes, the initial responsibilities include knowing some value or set

of values. We call these knowledge responsibilities.We indicate the type or object that the re-

sponsibility returns on the CRC card.

Scenario Walk-Through To further expand the responsibilities of the classes and see how they

collaborate, we must pretend to carry out various processing scenarios by hand. This kind

of role-playing is known as a walk-through. It is a different process than the algorithm walk-

through discussed in Chapter 4. An algorithm walk-through is intended to verify an algorithm.

Entry

Name

Address

Work address

Phone number

E-mail

Birthday

User interface

T

E

A

M

F

L

Y

Team-Fly®