Java Reference
In-Depth Information
Introducing Operations (Chapter 20)
SOLUTION 20.1
C
HAIN OF
R
ESPONSIBILITY
distributes an operation across a chain of objects. Each method
implements the operation's service directly or forwards calls to the next object in the chain.
SOLUTION 20.2
The figure shows one algorithm—the procedure to determine whether an object model is a
tree—two operations,which appear as two signatures in the
MachineComponent
class, and
four methods.
SOLUTION 20.3
No. If you change the return value of
MachineSimulator.clone()
, it won't compile.
The
clone()
signature matches the signature of
Object.clone()
, so the return type must
match as well.
SOLUTION 20.4
The program prints
"false"
. Static methods are invoked with reference to an object's
declared type, not with reference to the particular object. The type of
r
is
Firework
, so
r.flies()
returns
false
.
SOLUTION 20.5
•
One argument for the presence of checked and unchecked exceptions
: The Java
designers had it right: Listing
NullPointerException
and potentially dozens of
other common exceptions on every method would needlessly clutter my code with
dreck that I'd eventually learn to ignore.
•
On the other hand
: I think we can agree that we need an architectural approach to
handling exceptions, and we need a solid test environment that minimizes the chances
of runtime problems. Assuming that we had those facilities, what do we need
the compiler to do for us, regarding exceptions? My answer is, "nothing." I'd prefer to
have my IDE let me right-click on a method to see all the exceptions that can emerge,
along with where they're caught in my architecture and what test cases cover these
exceptions. Sound advanced? Maybe, but specifying exceptions as checked and
unchecked merely papers over a complex topic that deserves much deeper
consideration. While we await better IDE support, I'd vote for no having no "checked"
exceptions and, as I say, an architecture that comprehends exception handling and
a good test environment.
