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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
