commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (Commented) (JIRA)" <>
Subject [jira] [Commented] (CSV-68) Use Builder pattern for CSVFormat
Date Fri, 16 Mar 2012 16:49:39 GMT


Sebb commented on CSV-68:

bq. how about renaming init(char) to withDelimiter(char)

The delimiter is different, in that it is the only parameter that must be specified.

But one could still potentially have a withDelimiter() method that could be applied to an
existing Builder chain, e.g. to modify an existing format. [The builder delim field is final.
I might well change that and add the method.]

Note that the first and last methods in the chain have different input/output classes, so
should use a different naming convention.

"CSVFormat.init()" could be replaced by "new CSVFormat.Builder()" but I thought it was slightly
neater to have a static "newInstance()" method, and given that the delimiter needs to be defined,
I thought it might as well be a parameter to the init() method.

The init() method can of course be renamed. 
It cannot be renamed to withDelimiter() unless the existing method of the same name is dropped;
but even without the name clash I think it would be a mistake to use a name prefixed "with"
as the "newInstance" method as users would expect to be able to provide the parameters in
any order.

Just realised that this would also be possible if each withMethod were defined as a static
method in CSVFormat as well as a class method in the Builder. [Only the build() method would
be unique to the Builder.]

The only extra method call required would then be the build() method.

So the syntax would be


Maybe that would satisfy everyone?
> Use Builder pattern for CSVFormat
> ---------------------------------
>                 Key: CSV-68
>                 URL:
>             Project: Commons CSV
>          Issue Type: Improvement
>            Reporter: Sebb
>         Attachments: CSV-68.patch
> Using a builder pattern to create CSVFormat instances would allow the settings to be
validated at creation time and would eliminate the need to keep creating new CSVFormat instances
whilst still allowing the class to be immutable.
> A possible API is as follows:
> {code}
> CSVFormat DEFAULT = CSVFormat.init(',') // delimiter is required
>         .withEncapsulator('"')
>         .withLeadingSpacesIgnored(true)
>         .withTrailingSpacesIgnored(true)
>         .withEmptyLinesIgnored(true)
>         .withLineSeparator("\r\n") // optional, as it would be the default
>         .build();
> CSVFormat format = CSVFormat.init(CSVFormat.DEFAULT) // alternatively start with pre-defined
>         .withSurroundingSpacesIgnored(false)
>         .build();
> {code}
> Compare this with the current syntax:
> {code}
> // internal syntax; not easy to determine what all the parameters do
> CSVFormat DEFAULT1 = new CSVFormat(',', '"', DISABLED, DISABLED, true, true, false, true,
> // external syntax
> CSVFormat format = CSVFormat.DEFAULT.withSurroundingSpacesIgnored(false);
> {code}
> As a proof of concept I've written skeleton code which compiles (but needs completing).

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message