Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of ralph.goers@dslextreme.com
 designates 209.85.200.172 as permitted sender)
Message-ID: <490CA1AC.1070307@dslextreme.com>
Date: Sat, 01 Nov 2008 11:36:28 -0700
Reply-To: rgoers@apache.org
User-Agent: Thunderbird 2.0.0.17 (X11/20080925)
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [configuration] Interface vs class
References: <49095D30.60005@oliver-heger.de>
	 <ffdd47e0810300543g6decb5a2r86f5aaee45a51bbf@mail.gmail.com>
	 <4909C006.7000306@dslextreme.com> <gefo6s$cbp$1@ger.gmane.org>
 <f2e8eedf0810311323r7571c738t3d95ae7fbb362004@mail.gmail.com>
 <490C862C.2080000@oliver-heger.de>
In-Reply-To: <490C862C.2080000@oliver-heger.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
From: Ralph Goers <ralph.goers@dslextreme.com>

I believe this is the only discussion on 2.0 I've seen on the dev list. 
I went and scanned the archives a while ago. Rereading this thread I 
don't really see a decision to use an Abstract class.  I'm not sure I 
understand the discussion about which is more extendable. Yes, an 
abstract class means you can provide a dummy implementation, but this is 
only of value if there are implementations of that extend it outside the 
project. I also tend to believe that thinking that you are somehow 
better off with the abstract class is a fallacy. In many cases the 
method you will be provide will either do nothing useful or will be 
inappropriate for the "real" implementation. In both cases the 
implementation class will still have to be modified to provide an 
appropriate implementation of the new method. But worse, you won't get 
an indication that things are "broken" because the method will be there. 
If you were using an interface the problem would be apparent at load 
time and the implementation would have to change to be compatible with 
the new release.

BTW - there is no reason you can't have an interface and an abstract 
base class.

Ralph

Oliver Heger wrote:
>
> I found a reference to the original discussion. It came up when we 
> talked about new features for Configuration 2.0:
>
> http://www.nabble.com/-configuration--What-changes-in-Commons-Configuration-2.0---td15530059.html 
>
>
> 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.
>
> Oliver
>
> ---------------------------------------------------------------------
> 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