commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject [configuration] Interface vs class
Date Thu, 30 Oct 2008 07:07:28 GMT
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.



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

View raw message