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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
