Skip to main content

Property Problems, Solutions and Wishes

Posted by evanx on January 11, 2007 at 1:50 AM PST

Property Problems

Here are some problems and possible solutions (today) relating to bean properties.


Getters and Setters

Problem. We don't wanna write
lots of getters and setters, or see them.

Solution. We use our IDE to generate them.

Wishlist. Maybe we wanna fold basic getters and setters
right out of view en masse.

Another Wishlist. People wanna see the introduction of property keywords
eg. property, readonly, etcetera. Personally, i'm happy
with getters and setters with the help of my IDE.


Property References

Problem. Property names are strings,
which are not geared for IDEs (besides being highlightable
as strings as opposed to numbers and keywords). So we can't expect,
and don't get any help from our IDE, or even compiler. All we can
expect is runtime errors, D'oh!

Solution. We unit test our code
so that we catch problems before they can hurt us at runtime.

Further Solution. We might implement BeanInfo meta-classes
where we explicitly expose the bean property descriptors.
For example, in Gooey Beans Info,
we introduce a PropertyDescriptor wrapper with methods that our forms and
table models will invoke eg. property.get(bean) and property.set(bean, value), which
support validation, type conversion, and throw useful exceptions.

Wishlist. I wish for a language notation eg. Person@surname to
access a PropertyDescriptor
in a convenient, auto-completable,
verifiable and refactorable way in my favourite IDE.


Bound Properties

Problem. Lazy people like me don't wanna implement
all the JavaBean boilerplate to fire PropertyChangeEvent's.

Solution. We can use AOP to introduce PropertyChangeSupport and
fire PropertyChangeEvent's, eg. using CGLIB.
We use our explicit BeanInfo meta-class as a factory to create our enhanced beans.
(I'll try this out in a follow up blog.)

Wish. I wish my favourite IDE could create new Java Beans (with PropertyChangeSupport)
and generate setters which fire PropertyChangeEvent's,
and code-fold them to look like POJO's with regular setters.

Further Wish. I wish for a standard tool in my favourite IDE's
default build process, for annotation processing for compile-time AOP code generation,
to enhance classes ala Spoon at compile-time.
This could support a @JavaBean aspect annotation to request that a POJO be enhanced into a Java Bean
ie. having observable properties.


style="text-decoration: none;">
style="text-decoration: none;">
style='text-decoration: none;'>

This article is updated at the following permalink.

style="text-decoration: none;">



-->

Related Topics >>