[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    Re: [configuration] Interface vs class
From:       "Samuel Le Berrigaud" <samuel.lb () gmail ! com>
Date:       2008-10-31 23:09:12
Message-ID: df308a980810311609t694ae9a7s7a5cd4a5c6550561 () mail ! gmail ! com
[Download RAW message or body]

Hi,

I have not been in the conversations before, but I am also a proponent
of using interfaces. One way to enable extensions for those interfaces
would be to use the capability pattern (similar to what is described
here: http://java.dzone.com/news/the-capability-pattern-future- ).

There could be a ListCapability for example that would have the
setListDelimiter method for which the implementation would set it
directly on the abstract implementation of the configuration object.
No need for an ugly cast, and fairly easy to change the
implementation.

What do you think?

SaM

On Sat, Nov 1, 2008 at 9:04 AM, Mario Ivankovits <mario@ops.co.at> wrote:
> Hi!
> 
> > > Look through the archives, the discussion with pros and cons went on
> > > promoting commons-proxy.
> > 
> > Yes they did!  I remember it well and I hated using a class rather
> > than an interface.  However, I can see the merit in the decision when
> > it comes to maintenance and backward compatibility.  As a "purist", it
> > just hurt! ;)
> 
> Yep, sooner or later it hurts.
> 
> Everytime I cross the bridge having the requirement to create a facade or proxy for \
> a class based on just an abstract class it is a pain in the a*. 
> Sooner or later you'll find methods with an implementation in there and then you'll \
> face any sort of problem. 
> JSF is a very good (or bad) example where over the time it gets harder and harder \
> to extend from a grown abstract base class. Java itself has some interesting \
> classes, e.g. Authenticator or SSLSocketFactory. Stuff I had to deal with today. 
> Having an interface (which is extensible too, just extend an interface from another \
> one) makes this much more cleaner. Any problem after an upgrade (major release \
> upgrade for sure) the compiler will complain. Having abstract basis classes you can \
> avoid this, but your application might fail on runtime later ... or not ... \
> depending what you use from the inherited class. If you inherit from an interface \
> you can be sure that you fulfill the contract of the library, an abstract class can \
> change without any notice. 
> For me, the trend to abstract basis classes are a bad thing.
> 
> Ciao,
> Mario
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]