commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [configuration] Interface vs class
Date Sat, 01 Nov 2008 16:39:08 GMT
James Carman schrieb:
> On Fri, Oct 31, 2008 at 4:01 PM, Jörg Schaible <> wrote:
>> Hi Ralph,
>> Ralph Goers wrote:
>>> FWIW, I agree. I must have missed the earlier discussion as well.  I
>>> definitely prefer having an interface that can be used whenever a
>>> specific implementation is not required.
>> The original arguing was, that an interface will always prevent an
>> enhancement because of backward compatibility. This is especially true for
>> the current Configuration code base.
>> Whenever I get a Configuration object passed, I cast it quite immediately to
>> an AbstractConfiguration to set the delimiter and throw mode. If
>> Configuration itself were an abstract class, those methods could have been
>> added long ago without breaking backward compatibility.
>> 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! ;)

I found a reference to the original discussion. It came up when we 
talked about new features for Configuration 2.0:

As you can see I was also pro interfaces. However the issue of backwards 
compatibility is really important for projects like Commons providing 
basic libraries.

I was always on the opinion that our Configuration interface is too fat. 
About 80% percent of its methods actually deal with data conversion. So 
my intention is to separate basic operations for accessing properties 
from high-level convenience methods.

Interfaces are especially useful where you expect multiple 
implementations. This is the case for the part I called 
ConfigurationSource, i.e. the actual management of configuration 
properties. It is not the case for stuff like data conversions. We will 
implement this once and use it throughout the library. Thus it is fine 
with me having a class that provides a richer API built on top of the 
fundamental ConfigurationSource interface. The class merely serves as a 
kind of decorator; you can still pass the ConfigurationSource objects 
around, which contain the actual content.

The names I used - ConfigurationSource for the interface and 
Configuration for the decorator class - may not be the best choice though.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message