Open GoogleCodeExporter opened 9 years ago
Nice idea - we were thinking about something more, less similar:
PersonBuilder.person(instance).....
, but in my opinion it should return a copy of the existing object (what is
quite complicated, cause You don't always know how to copy some fields or You
should omit some). The main idea of our plugin is not to be intrusive on an
existing code (actually it comes from the fact that most of the time we use it
for fixturing the POJO's for testing and sometimes code of POJO's are in the
other artifact...)
This seems like a great idea, but still need some thinking and coding things
we've already planned :).
Thanks a lot for the idea, hope our plugin is helpful.
(attaching pawelw, he has more thoughts about that AFAIR).
Original comment by kube...@gmail.com
on 23 Sep 2010 at 5:56
Original comment by kube...@gmail.com
on 23 Sep 2010 at 1:07
Hello "kubek2k".
1.)
I like the idea with the
PersonBuilder.person(instance).with...
So you don't have to put code into the pojo/bean class and don't make any
unnecassary dependencies in "Person".
2.) Copy or not:
Maybe also a good idea? Offering 3 fluent if constructors like this:
PersonBuilder.create().with... (create a new insance)
PersonBuilder.modify(instance).with... (modify the instance)
PersonBuilder.clone(instance).with... (your idea, return a copy).
3.)
Also a nice idea, but lot of work:
the plugin can give you warnings, when a pojo was modified (new setters added)
and
the generated fluent interface is not acutal (out-of-sync), and the user can
recreate
the fluent interface.
The easiest solution is:
having a naming convention: Person -> PersonBuilder.
If Person is newer then PersonBuilder must be recreated.
4.)
The performance is realy good, because the plugin is generating code.
Only ~ 40-50% slower then to use the bean methods.
If you look to ideas like
http://codemonkeyism.com/fluent-interface-and-reflection-for-object-building-in-java/
This solutions are 100x (times) slower the your plugin.
Thanks for your feedback
Ula
Original comment by ula.uvula@gmx.de
on 23 Sep 2010 at 5:46
2) nice idea, but it stops being a real builder, but worth thinking about
3) I don't why, but You're not the first person that asks for that :). The
problem is that it would make the plugin too complicated, intrusive and
additionally it would hurt IDE performance a lot. My point of view on that is -
if You add a field to the POJO, and You need to change the builder
respectively, You just regenerate the builder. I'm not sure whether effort put
into the more complicated solution would percent.
4) Nice to hear that - funny thing is, that internally builders that You've
shown are more interesting, but the problem is that it's quite hard to maintain
it, especially when You want to have'em similar features, as ours.
thats my 2p :)
Kuba
Original comment by kube...@gmail.com
on 24 Sep 2010 at 11:59
Original issue reported on code.google.com by
ula.uvula@gmx.de
on 22 Sep 2010 at 10:42