commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Fabulich (JIRA)" <>
Subject [jira] Commented: (BEANUTILS-335) Provide support for "fluid" beans
Date Tue, 24 Feb 2009 21:51:02 GMT


Dan Fabulich commented on BEANUTILS-335:

I'd like to say a few points in defense of this code, but then I'll just migrate this discussion
over to the commons-dev mailing list.

It's not entirely clear to me whether Niall is saying that fluid beans are merely inappropriate
for inclusion in BeanUtils, or whether he thinks that the very idea of fluid beans is generally
without merit.  

For the record, I think fluid beans are at least as useful as DynaBeans.  Specifically, I
think chained getters/setters are a little better (and more Java-like) than dynamic expressions,
because my IDE can autocomplete static method names, because I don't have to cast the return
value (it's already automatically type-safe), and because the compiler can catch errors before

So, supposing that fluid beans are useful... are they appropriate for inclusion in BeanUtils?
 I'm not as sure about that, but I do think so.

Niall argues that BeanUtils has always been based on the JavaBeans standard, but fluid beans
aren't.  But BeanUtils already provides lots of support for non-standard beans.  For example,
it supports non-standard "mapped" properties in addition to standard "indexed" properties.
 And DynaBeans can't even be introspected by the java.beans.Introspector; they don't follow
the JavaBeans naming standard at all.

For comparison, the standard java.beans.Introspector can discover and use fluid methods. 
AbstractFluidBean extends SimpleBeanInfo, overriding getPropertyDescriptors.  If you define
a bean that extends AbstractFluidBean, all of the rest of the BeanUtils will work just fine
with your new fluid bean.  (You can even configure a fluid bean with the NetBeans GUI Builder.)

Ultimately, if BeanUtils is just a library to _dynamically_ manipulate beans, then, yes, fluid
beans are clearly out of scope.  But if BeanUtils is meant to be a perfectly general library
of convenient utilities for working with beans, then I think we should strongly consider including
this code (or something like it) in BeanUtils.

> Provide support for "fluid" beans
> ---------------------------------
>                 Key: BEANUTILS-335
>                 URL:
>             Project: Commons BeanUtils
>          Issue Type: New Feature
>          Components: Bean / Property Utils
>            Reporter: Dan Fabulich
>         Attachments:
> The attached patch allows users to easily define what I'm calling a "fluid" bean (though
there might be a better name for it).
> The idea here is to write a bean that doesn't follow the standard JavaBean convention.
 Specifically, a "fluid" bean's setters return "this," so you can "chain" calls to the setters,
and the getters and setters don't start with "get/set" but are just the name of the property.
 For example:
> {code}public class Employee extends AbstractFluidBean {
>   private String firstName, lastName;
>   public String firstName() { return firstName; }
>   public Employee firstName(String firstName) {
>     this.firstName = firstName;
>     return this;
>   }
>   public String lastName() { return lastName; }
>   public Employee lastName(String lastName) {
>     this.lastName = lastName;
>     return this;
>   }
> }{code}
> Fluid beans have some limitations: you can't use indexed or mapped properties with a
fluid bean (because there's no way to disambiguate an indexed getter from a simple setter).
 I think that's OK because indexed properties are a bit silly. (Why not just return a List
or a Map?)
> But I think they have substantial readability advantages.  With a fluid bean, you can
write code like this:
> {code}
> HumanResources.hire(new Employee().firstName("Dan").lastName("Fabulich"));
> {code}
> For an example of fluid chained setters in the wild, see (for example) Effective Java
Second Edition by Joshua Bloch.  In Item 2 "Consider a builder when faced with many constructor
parameters" Bloch defines a fluid bean with chained setters, so you can use it like this:
> {code}
> NutritionFacts cocoCola = new NutritionFacts.Builder(240, 8)
>   .calories(100).sodium(35).carbohydrate(27).build();
> {code}

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message