commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
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 <oliver.heger@oliver-heger.de> 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]
>> http://svn.apache.org/viewvc/commons/proper/configuration/branches/configuration2_experimental/src/main/java/org/apache/commons/configuration2/base/ConfigurationSource.java?view=log
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>>     
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>   

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


Mime
View raw message