+1 for builder pattern and fluent API On Mar 16, 2012 4:24 AM, "Benedikt Ritter" <benerit...@googlemail.com> wrote:
> Am 15. März 2012 21:20 schrieb Emmanuel Bourg <ebo...@apache.org>: > > Le 15/03/2012 20:26, Benedikt Ritter a écrit : > > > > > >> How about you Emmanuel? Could sebb convince you? ;-) How about this: > >> I'll create a patch and attach it to JIRA. Then we'll have a better > >> basis for discussion. > > > > > > Sorry but I'm not convinced. I see exactly where this leads. > > > > Hey Emmanuel, > > I accept that, and I respect your decision. I don't want to argue with > you on this, I just want to understand your decision. From Effective > Java, I learned "if you are facing a constructor with lots of optional > arguments, consider using the builder pattern". Can you explain, why > you think it is not appropriate in this case? You said it is too > verbose, but it's just one additional call, compared with what we have > now. > > The advantage of the builder (sorry now I'm arguing :) is, that nobody > has to remember to validate the format. Even if validation is > something that is package private, that could lead to the point where > someone forgets to add that line. Now you could say we have unit tests > for that. But isn't it the responsibility of an object to verify that > it is being instantiated into a valid state? > Also we don't know yet, if there always will be only one package in > the library. What if, we add another package (o.a.c.csv.beanmapping or > what ever) and we want to use CSVFormat there. Then we would have to > make validate public, exposing it to the outside world. > > > If you have some free time and want to do something fun you can try > > reimplementing the parser with less array copies. Commons CSV is still > > behind the other APIs on the performance side. > > > > I'll have a look at that, and at what Ted suggested on the other thread. > > TIA for taking your time to explain!! > Benedikt > > > Emmanuel Bourg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
