commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject Re: [configuration] Interface vs class
Date Wed, 05 Nov 2008 18:57:22 GMT
Simon Kitching wrote:

> So the rule would be:
> * the project provides both an interface and an abstract class that
> implements that interface.
> * code that *uses* the API should always use just the interface, ie
> *call* methods via the interface and pass instances around as the
> interface type
> * code that *implements* the API should always subclass the base class.
> The project reserves the right to add methods to the interface, but will
> always provide a concrete default implementation on the abstract
> subclass. Methods will *not* be added to the interface if a sensible
> default implementation cannot be provided.
> That sounds like a pretty good approach to me; seems to ensure maximum
> backward compatibility while keeping a clean interface-based API (which
> allows interface-based proxies to be generated at runtime).
> I would agree with Jörg here, that as long as release-notes document
> expected clirr incompatibilities there is no problem. Clirr can of
> course be configured to ignore specific classes when processing...

Exactly ... it's always nice to get a clean summary by a native speaker :)

- Jörg

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

View raw message