Java Reference
In-Depth Information
callers don't need to worry about checked exceptions.
get()
also runs the extra Java 5
mile and casts the result
F
to the expected type, so callers don't need an explicit cast
when assigning it to a variable.
14
The dirtiest part is getting the
Field
reference
G
; this method has to scan all
methods of the object's class
H
and its superclass
J
, and once the method is found, it
must be made accessible
I
.
Going back to our
UserFacadeImpl
example, once it doesn't offer a setter for
UserDao
and these new helper methods are available, we could rewrite the
facade.
setUserDao(dao)
statement on
UserFacadeImplTest.setFixtures()
(defined in list-
ing 19.5) as
TestingHelper.set(facade, "userDao", dao);
Bypassing encapsulation, or how I learned to stop worrying
and love reflection
One of the first things you learn when studying object-oriented languages is that
they're built on three pillars: encapsulation, inheritance, and polymorphism. And
encapsulation best practice dictates that attributes should be defined as private
and accessed only through getters and setters. As a good student and disciplined
developer, you follow that practice and happily declare all your object fields as pri-
vate, using a few hotkeys from your favorite IDE to generate those boring getters
and setters. Then after a hard day at the office, you decide to read a few more
pages of this topic at home to relax, when you read something disturbing: those
tightly encapsulated fields that you protected with so much care can be easily
accessed throughout reflection! Your whole world falls apart, and your first
instinct is to sell all your Java topics and buy Y2K survival kits with the few bucks
you get from the sale. Well, if that happens to you, please go back to the couch
and relax again: you can only bypass encapsulation if you grant the permissions to
the JVM to do so. More specifically, when you call methods such as
Field.set-
Accessible(true)
, the JVM will first check with the
SecurityManager
to see if
the calling method has permission to change the accessibility rules. You could
argue that the permission is granted by default and hence the fields are wide
open, but the truth is that such behavior is convenient most of the times, at least
in the Java SE environment.
Anyway, the fact that such access is allowed or not by default is out of the scope of the
book. Even if the
JVM
had a more strict default behavior, you could still configure the
SecurityManager
to lower the restrictions in your test case environment.
14
This might sound like black magic, but what happens is that the compiler knows what type is expected and
does the proper casting (because the method returns a parameterized type,
<T>
). That doesn't eliminate
ClassCastExceptions
at runtime, but it does make the code cleaner, which is particularly welcome in test
cases (in fact, many tools analyzed in the topic, such as EasyMock and FEST, use this trick).
