commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Crum <>
Subject Re: [CSV] Extract interfaces?
Date Sun, 24 Mar 2013 09:56:50 GMT
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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message