commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Bourg <>
Subject Re: [csv] Why does CSVFormat provide a validate() method instead of validating parameters passed to its constructor?
Date Fri, 16 Mar 2012 09:45:55 GMT
Hi Benedikt,

> 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.

You said it, it's an additional call. For [csv] I'd like to focus on a 
simple and user friendly API. "Effective Java" is a good reference, but 
I think we should find a balance between theorical "by the book" 
perfectness and user friendliness.

> 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?

There was no validation before and nobody complained. I think no other 
CSV API validates its parameters. I thought it was harmless and 
convenient to add it, but now if it's used as an argument to make the 
API more verbose I'd rather remove it completely.

> 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.

Well, why not if that's necessary at this time.

Emmanuel Bourg

View raw message