On Sat, Mar 23, 2013 at 8:59 AM, Thomas Neidhart <thomas.neidh...@gmail.com>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. > I agree with Thomas. Let's not create a JDBC for CSV unless one is needed. For 1.0, I want to something that works and is simple to use. Gary > 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 > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
