Have a look at the sample builder implementation in https://issues.apache.org/jira/browse/CSV-68
On 16 March 2012 09:45, Emmanuel Bourg <ebo...@apache.org> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
