(^284) | Object-Oriented Software Design and Implementation
city, state, and ZIP code, and those are already on my list.” User Interface says, “I can con-
catenate the last three to form the second line, so that satisfies the collaboration.” The col-
laboration is recorded, and User Interface says, “Now I display the information, and I’m done.”
The last card is lowered and the scenario ends.
Reading about the scenario makes it seem longer and more complex than it really is. Once
you get used to role-playing, the scenarios move quickly and the walk-through becomes more
like a game. However, to keep things moving, it is important to avoid becoming bogged down
with implementation details. Book should not be concerned with how the Entry objects are or-
ganized on the list. Address doesn’t need to think about whether the ZIP code is stored as an
intor a String. Merely explore each responsibility in enough depth to decide whether a fur-
ther collaboration is needed or if it can be solved with the available information.
Subsequent Scenarios We began the first scenario with a “What happens when.. .” question for the
most obvious case.The next step is to brainstorm some additional questions that produce new
scenarios. Consider the following list of some further scenarios for our address book example:We walk through each of the scenarios, adding responsibilities and collaborations to
the CRC cards as necessary. After several scenarios have been tried, the number of additions
decreases. When one or more scenarios take place without adding to any of the cards, we
brainstorm further to see if we can come up with new scenarios that may not have been cov-
ered yet. When all of the scenarios that we can envision seem to be doable with the existing
classes, responsibilities, and collaborations, then the design is finished.
When our design is complete, we can implement the responsibilities for each class. The
implementation may reveal details of a collaboration that weren’t obvious in the walk-through.
Of course, knowing the collaborating classes makes it easy to change their corresponding re-
sponsibilities. The implementation phase should also include a search of available class li-
braries to see if any existing classes can be used. For example, thejava.util.GregorianCalendar
class represents a date that can be used to implement Birthday.What happens when the user
asks for a name that's not in the book?
wants to add an entry to the book?
deletes an entry?
tries to delete an entry that isn't in the book?
wants a phone number?
wants a business address?
wants a list of upcoming birthdays?