Java Reference
In-Depth Information
Exercise 12.3
Examine the implementation of the
AddressBook
class and assess
whether you think it has been well written or not. Do you have any specific criticisms of it?
Exercise 12.4
The
AddressBook
class uses quite a lot of classes from the
java.util
package; if you are not familiar with any of these, check the API documentation to fill in the
gaps. Do you think the use of so many different utility classes is justified? Could a
HashMap
have been used in place of the
TreeMap
?
If you are not sure, try changing
TreeMap
to
HashMap
and see if
HashMap
offers all of the
required functionality.
Exercise 12.5
Modify the
CommandWords
and
AddressBookTextInterface
classes
of the
address-book-v1t
project to provide interactive access to the
getDetails
and
removeDetails
methods of
AddressBook
.
Exercise 12.6
The
AddressBook
class defines a field to record the number of entries.
Do you think it would be more appropriate to calculate this value directly, from the number of
unique entries in the
TreeMap
? For instance, can you think of any circumstances in which the
following calculation would not produce the same value?
return book.size() / 2;
Exercise 12.7
How easy do you think it would be to add a
String
field for an email address
to the
ContactDetails
class, and then to use this as a third key in the
AddressBook?
Don't actually try it, at this stage.
12.2
Defensive programming
12.2.1
Client-server interaction
An
AddressBook
is a typical server object, initiating no actions on its own behalf; all of its
activities are driven by client requests. Implementers can adopt at least two possible views
when designing and implementing a server class:
■
They can assume that client objects will know what they are doing and will request services
only in a sensible and well-defined way.
■
They can assume that server objects will operate in an essentially problematic environ-
ment in which all possible steps must be taken to prevent client objects from using them
incorrectly.
These views clearly represent opposite extremes. In practice, the most likely scenario usually
lies somewhere in between. Most client interactions will be reasonable, with the occasional
attempt to use the server incorrectly—either as the result of a logical programming error or of
misconception on the part of the client programmer. A third possibility, of course, is an inten-
tionally hostile client who is trying to break or find a weakness in the server.
Search WWH ::
Custom Search