commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Samuel Le Berrigaud" <samuel...@gmail.com>
Subject Re: [configuration] Interface vs class
Date Fri, 31 Oct 2008 23:09:12 GMT
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


Mime
View raw message