commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [csv] final types
Date Tue, 06 Aug 2013 13:18:50 GMT
On Tue, Aug 6, 2013 at 8:43 AM, James Carman <james@carmanconsulting.com>wrote:

> I am also -0 to this idea in general.  Are we talking about literally
> making all classes final?
>

I think there are two points in the "+0" camp, if I can call this camp such
that I'd like to outline.

1) Promote composition over subclasssing as a customization pattern. This
is a design point that is philosophical for some. I, for one, think
composition less brittle. As has been argued in other threads, primitive
access methods do not belong in CSVRecord (at least not in 1.0, the record
is not a JDBC ResultSet with all of its get methods.) If they do not belong
in the class, they should not be in a subclass either IMO. Composition
works best here it seems. Your mileage may vary. For the same reason, a
Customer class should not subclass CSVRecord. If someone argues that a
domain class is a kind of record, then I'd argue that conversion methods
belong in the record.

2) We can make final classes extensible after 1.0, but we cannot make
non-final classes final in 1.x without breaking compatibility.

The current code, IMO, is not really designed for customization by
extensibility, otherwise, for example, I'd expect CSVParser to have a
method called newRecord(), in addition to nextRecord().

Discuss! ;)

Gary


> On Tuesday, August 6, 2013, Gary Gregory wrote:
>
> > I think the idea is that it promotes composition instead of
> > subclassing as the extension pattern.
> >
> > If I wanted the parser to produce a different kind of record,
> >
> > Gary
> >
> > On Aug 6, 2013, at 4:44, Emmanuel Bourg <ebourg@apache.org<javascript:;>>
> > wrote:
> >
> > > Le 05/08/2013 19:34, Gary Gregory a écrit :
> > >
> > >> Thoughts?
> > >
> > > -0, that's not very friendly to people willing to extend [csv].
> > >
> > > Emmanuel Bourg
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> <javascript:;>
> > > For additional commands, e-mail: dev-help@commons.apache.org
> <javascript:;>
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org<javascript:;>
> > For additional commands, e-mail: dev-help@commons.apache.org
> <javascript:;>
> >
> >
>



-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message