commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ivankovits <>
Subject RE: [configuration] Interface vs class
Date Fri, 31 Oct 2008 22:04:52 GMT

> > 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.

View raw message