Gary Gregory wrote: > 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.
+1 - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
