commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [configuration] Interface vs class
Date Thu, 30 Oct 2008 14:09:10 GMT
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.

Michiel Kalkman wrote:
> I don't know the discussion, so the only thing I can say right now, is
> that I don't like the names ... Or I just don't understand why it is
> called XXXSource, which in my thoughts refers to the resource the
> configuration is read from.
> How about Configuration for the interface and something like
> BaseConfiguration for the class ?
> Regards,
> Michiel
> On 10/30/08, Oliver Heger <> wrote:
>> A while ago we discussed whether in Configuration 2.0 the fundamental
>> Configuration object should be an interface or an (abstract) class, and
>> - as usual ;-) - we could not agree on a way to go.
>> Therefore I suggest the following compromise:
>> We keep an interface - let's call it ConfigurationSource - that is a
>> stripped down version of the Configuration interface we have now. This
>> interface contains only basic operations needed for accessing properties in
>> their "raw" form.
>> What is now AbstractConfiguration can become a concrete class
>> "Configuration". This class will be associated with a ConfigurationSource
>> object and implement more sophisticated operations on top of it. Here stuff
>> like data conversion, interpolation, or enhanced query facilities is
>> implemented.
>> An advantage of this approach is that we have a cleaner separation between
>> the basic management of configuration properties and high-level processing
>> of their values. We still have an interface, which has benefits, e.g. for
>> providing mock implementations or proxies, but extensions can be implemented
>> in a binary compatible way by modifying the new Configuration class (and
>> maybe defining sub interfaces of ConfigurationSource). Because the
>> ConfigurationSource interface has only a handful of methods, it is easier to
>> implement than the overloaded Configuration interface of today.
>> I checked in a first draft version of a ConfigurationSource interface [1].
>> Of course we can discuss the methods this interface should have. For
>> instance, methods like flush() and sync() dealing with persistence could be
>> added.
>> WDYT?
>> Oliver
>> [1]
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message