Traditionally, many commons projects has taken no position on the
correct way to instantiate objects, whether via constructor or bean
methods. This was to allow construction from tools such as Velocity.
It is also still easier to construct using Spring via bean methods
rather than the constructor.
These days, immutability and concurrency are more important, so this
change may be applicable, buts its good to understand the history and
wide use cases of classes like these.
Stephen
On 29 January 2011 12:04, Jacopo Cappellato <jacopo.cappell...@gmail.com> wrote:
> Hi all,
>
> in my opinion all the setter methods should be removed from the CSVStrategy
> class: in this way the fields will only be set using the constructors and
> they will become readonly.
> The main issue I see with the current implementation is that a calling method
> can modify the values of the fields of the following static objects declared
> in CSVStrategy (changing the default behavior for all subsequent code that
> uses for example CSVStrategy.DEFAULT_STRATEGY):
>
> public static CSVStrategy DEFAULT_STRATEGY = new CSVStrategy(',', '"',
> COMMENTS_DISABLED, ESCAPE_DISABLED, true,
> true, false,
> true);
> public static CSVStrategy EXCEL_STRATEGY = new CSVStrategy(',', '"',
> COMMENTS_DISABLED, ESCAPE_DISABLED, false,
> false, false,
> false);
> public static CSVStrategy TDF_STRATEGY = new CSVStrategy('\t', '"',
> COMMENTS_DISABLED, ESCAPE_DISABLED, true,
> true, false,
> true);
>
> What do you think?
>
> Jacopo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
