commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <Joerg.Schai...@scalaris.com>
Subject RE: [configuration] Interface vs class
Date Mon, 03 Nov 2008 09:18:39 GMT
Hi,

Ralph Goers wrote:
> 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. 

IMHO we should define what we want to reach. Adding a method to an interface does not break
*binary* compatibility of existing code. The method is simply not called. However, a client
will have to implement the new method, if CConf is a compile time dependency *and* he uses
an implementation not delivered by CConf. Maybe it is the best approach to have an abstract
base class and the interface. We have to tell our users, that they should extend from the
abstract class if they want to ensure backward compatibility for own implementations of the
Configuration interface. Point is, that it *is* only an advice/recommendation and something
like clirr will always report a violation in compatibility. Hoiwever, it is our desicion how
we should proceed.

- Jörg

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


Mime
View raw message