commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <jcar...@carmanconsulting.com>
Subject Re: [csv] Why does CSVFormat provide a validate() method instead of validating parameters passed to its constructor?
Date Fri, 16 Mar 2012 12:34:31 GMT
+1 for builder pattern and fluent API
On Mar 16, 2012 4:24 AM, "Benedikt Ritter" <beneritter@googlemail.com>
wrote:

> Am 15. März 2012 21:20 schrieb Emmanuel Bourg <ebourg@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message