Appendix B. Solutions- The name of each of a class's methods should be a good commentary on what the
method does.
SOLUTION 7.3.......................................................................................................................................
At least two earlier challenges have involved cases in which the effect of calling a method is
not completely predictable from the method name.
- Challenge 2.1 on page 14 asks about methods that do not imply responsibility on the
part of the implementing class to take action or to return a value. As the solution (page
359) suggests, when a class registers for notification calls, such as
mouseDragged(), the methods do not imply an obligation to the caller. - Chapter 6, Bridge, gives several examples showing that the effect of calling an
abstraction's methods depends on which driver or implementation is in place.
The effects of calling a method are purposely unpredictable when the method is part of an
abstraction and when the method exists to receive notification. In other cases, a method with
unforeseeable results may simply be misnamed.
The Java class libraries contain other examples of when you might not predict a method's
behavior from knowing its name. In particular, >Chapter 18, Prototype, asks you to take a
hard look at the behavior of Object.clone() in Challenge 18.3 on page 186.
SOLUTION 7.4.......................................................................................................................................
To keep another developer from burrowing into your package with subclasses that manipulate
protected members of your classes, you might
- Offer to add the function the developer needs
- Modify your instance variables with private visibility and use get- methods
within your own package - Declare classes like SolidRocket to be final, so that they cannot be subclassed