On 3/23/2013 12:59 PM, Thomas Neidhart wrote:
On 03/23/2013 12:41 PM, Benedikt Ritter wrote:
Hi,
while looking through the code, I was asking myself why we expose
implementation classes. Wouldn't it be better to extract interfaces from
CSVParser, CSVPrinter and CSVRecord? At least for the CSVRecord it would
make sense because users cannot create CSVRecord instances. Why binding
them to a concrete implementation?
Since CSVParser und CSVPrinter can only be created using the default ctor,
users would have to write something like (and though still defining a
dependency to the concrete implemenation):
CSVPrinter printer = new DefaultCSVPrinter(in, format);
It would even make sense to extract an Interface for Lexer and CSVLexer
although it is only used internally. Having an abstract class (Lexer) that
defines a abstract method, that is not used in one of the other methods,
but just defines an interface feels strange. And if we decide to expose the
lexer, so that users can plugin their own lexer implementations (for what
ever reason...) we would be set up for this.
I think it is important to make things not more complicated than
necessary. If there will be only one implementation of this interface
you do not gain anything by splitting it up.
In math we merged many of this interface/implementation constructs back
into a single class.
If there is a need to alter/tweak the behavior of a class you can still
subclass it, I guess.
Thomas
I agree. Interfaces would make sense if you expected to have many
different implementations.
-Adrian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
