Java Reference
In-Depth Information
•
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
