[
https://issues.apache.org/jira/browse/BEANUTILS-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676424#action_12676424
]
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
runtime.
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: https://issues.apache.org/jira/browse/BEANUTILS-335
> Project: Commons BeanUtils
> Issue Type: New Feature
> Components: Bean / Property Utils
> Reporter: Dan Fabulich
> Attachments: AbstractFluidBean.java
>
>
> 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.
