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.
Defensive programming
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
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