Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
String getFoo(); void setFoo( String newValue );
The BeanBox uses the introspection APIs of the
Class class to get a list of methods, then it uses pattern matching to find the getter/setter pairs. From these, it infers that
a property exists and determines the property's type. (In the current example, a property called
Foo is a
String.) You are never expected to call these methods yourself; they exist solely for use by the BeanBox.
Interestingly, the writers of the JavaBeans spec understood just how problematic this getter/setter tagging mechanism is.
(The main downside, discussed in earlier articles, is that the getter/setter methods expose too much information about the
object's implementation, thereby making the underlying class much harder to maintain.) Consequently, the designers provided
a more object-oriented solution in the
Customizer interfaces. User-provided implementations of these interfaces let you build a GUI without the getters and setters. Unfortunately,
this overly complicated object-oriented approach was described poorly in the spec. The getter/setter approach was easy, and
if you didn't understand the object-oriented-related maintenance issues, then the getter/setter approach seemed reasonable.
Customizer approach fell by the wayside and getter/setter strategies have been propagating like rabbits. The fact that you see the idiom
everywhere doesn't make it good, however.
Back when JavaBeans were first proposed, many people (including myself) argued for a new keyword in Java to eliminate the
need for the getters and setters. With the ability to introduce a new keyword, the
Foo property I described earlier could be represented as:
private @property String foo;
foo is private, exposing it to the BeanBox with the new keyword doesn't violate encapsulation. At the time, however, introducing
new keywords was anathema, even keywords impossible to confuse with existing identifiers because they included an illegal
With J2SE 5.0, however, Sun has gotten over its delicacy and made a few major syntactic changes to the language. Now, you
can introduce a new keyword (called an annotation) into the language to specify an attribute that can be examined at either compile-time or runtime. You may introduce arbitrary
keywords of your own choosing. The only requirements are: the annotation (the keyword) must be preceded with an
@ sign, and you must use the annotation as an adjective. (Annotations can go anywhere that you might say
public.) Finally, you can toss the getters and setters for a much cleaner syntax that does the same thing.
|Forum migration complete By Athen|
|Forum migration update By Athen|
|Getters/Setters By Tony Weston|
|An annotation-based persistence framework By JavaWorld|