> Piyush Purang <ppurang <at> gmail.com> writes: Hi Piyush, I share some of the same frustrations with fluent builders...
> Hi Sean, > > Honestly I didn't like the fluent builder because (apart from > aesthetically unpleasing upRouter() and a little hack of > owner().start()) > > a) problem with multiline statements (including compromised > readability). And to fit it all on a single line would mean unecessary > tinkering with checkstyle rules. (And that question about IDE code > formatters) Maybe it's a personal thing but I found the fluent style much easier to read, understand, and write. Here I created two applications as examples for our staff, one without and one with fluent style. It was a new configuration and I really struggled to write it w/o the fluent style. I understood exactly what calls to make to construct things, but the wiring was confounding. It was also hard to read and there were a few bugs I had to fix. The fluent example, on the other hand, was straightforward to write and had no bugs. Later in explaining the app to two people, one got really excited about the fluent style, the other was lukewarm. Maybe an indicator there's a personal preference component. > b) Size. how many methods should builder have? And do the builders have the ones I want? Yes, I understand this issue. But it's a developer's issue not a user's issue. I always have to ask myself, am I making this design choice to make my job easier, or my users' jobs easier. I wonder if some creative mix of polymorphism and inhertance might make this easier. In other words, have a single wiring method that is type safe for the set of acceptable next Restlets. If I recall, different Restlet types have different method names for wiring. OTOH, elaborate type hierarchies have their own problems. > c) problem with changing api both additions and deletions. (This is > inherent in XML based configurations too ) I don't see a way around this reality of SW development. Changing the API will have effects that cut across the codebase. I can imagine the builders pose a huge annoyance every time org.restlet changes occur. Hopefully that pain will fade as the API stabilizes. > d) What are the correct sequence of method calls? I've struggled with that. Patterns saved me except when I wanted to do something not described in the tutorial. Then I had to look at the source because there isn't much in the JavaDocs yet. > How do you document them? Not sure, but that was why I had to look at the source. Without devoting much thought, I sense patterns may be very useful. > Can you validate the code even before it is run? (Atleast with > XML I can have an XML schema that'll stop me from making obvious > mistakes.) Having spent the last two weeks banging my head against XML schemas, I don't find validation a particularly compelling argument for correctness. Anyway, it's not the obvious mistakes I waste most of my time on. Maybe this is what you mean: when something doesn't work, how the heck do I know what it is if all the calls are chained together? My experience is that I'm less likely to make errors using fluent and, if necessary, I can bust apart the chain and figure it out. Once it's right, it's more readable, more maintainable and, so far, pretty amenable to change. Where I work, we have a lot of mid- and junior-level developers and readability and maintainability are very important. We use the fluent style in other projects it has served us well. It seems to resonate here. > I don't have anything against "fluent" builders and I am not an ardent > fan of XML set of technologies. I rather like the example presented in > Fowler's exposition. I can accept that XML is appropriate for certain deployment configurations. I agree XML has been ab-used as a surrogate programming language for administrators and that's where the trouble starts. > Here I have tried to bring out the reasons why I gave the fluent > builder as highlighted by the tutorial a skip. Thanks for a thoughtful explanation of the issues, Piyush. For me, the benefit of the fluent style for this domain is worth the costs it admittedly has. Regards, Sean
