CASE STUDY^359
EXTENDING THE ADDRESS BOOK
Problem:In Chapter 6, we created a file that contained a simplified version of a comput-
erized address book. It was so successful, that we will now improve it in the following
ways:
Add a birthday to each entry.
Replace the text file with an object file.Brainstorming:Our problem statement implies that we should replace a PrintWriter
object with an ObjectOutputStreamobject. We don’t need to brainstorm about this
change, but we do need to think about what is involved in representing a birthday. A
birthday is a date, so we should have a month, day, and year. Do we need separate
classes for month, day, and year? Because each can be represented by an integer, let’s
let month, day, and year just be fields in the Birthday class.
Do we really need a year field? It isn’t polite to ask people how old they are, but
there is no harm in having a year. If we don’t know the year, we can just substitute a
value that represents “not known.”
Determining Responsibilities:Because we may be creating an entry without knowing
what the birthday is, we need a nonparameterized constructor that sets all the values
to “not known.”
What type of scenarios can we imagine for our Birthday class? Certainly, Entry will
send a message to Birthday asking for a copy, so “Know birthday” must be a responsibil-
ity. What else might Entry request of Birthday? Perhaps Entry might want to know if
Birthday is within a certain time period of a date. This task implies that the birthday
can be compared to another date.
We have called this class Birthday because that is its role in our Entry class. However,
it is really just a general date class. We should use Birthday as the field name in Entry,
but Date as the name of the class. Here, then, is the CRC card for the Date class:
Class Name: Date Superclass: Subclasses:
Responsibilities Collaborations