commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: [digester] initial code for Digester2.0
Date Wed, 02 Feb 2005 22:50:30 GMT
On Wed, 2005-02-02 at 06:04 -0800, Reid Pinchback wrote:
> --- Oliver Zeigermann <> wrote:
> > On Wed, 02 Feb 2005 18:28:04 +1300, Simon Kitching <>
> > > My major concern is that if we are going to warn people not to implement the
Action interface,
> > > then what really is the point of providing it in the first place? As I said
above, I just
> > cannot
> > > think of any situation where a class would want to be an Action *and* extend
some other class.
> >
> > I am +1 for using an interface and the default (why abstract?)
> > implementation like with Swing or SAX.
> I don't get why we would ever warn people not to implement the interface

We (digester developers) want the ability to add methods to Action in
minor releases. But adding methods to an interface breaks all classes
that directly implement that interface.

So people should not extend an Action interface because their classes
could be broken by a minor-version update of Digester, eg 2.0 -> 2.1.

They wouldn't be forbidden from implementing Action, just warned about
the consequences.

By encouraging users to extend AbstractAction instead of implementing
Action, we have the chance to provide default implementations for new
functionality, and thereby give ourselves the chance to improve digester
in minor releases without breaking user code.

> Here is a concrete example of why you could want to implement the interface
> and extend another class, I've actually had situations with the existing
> Digester where I'd wished I could do that.  The one that I can recall now
> was an instrumentation issue.  Doing debugging and performance tuning of
> a suite of rules can be tedious because, currently, the only options are
> either to watch a spew of logging messages or single-step your way through
> all the callbacks in a debugger (PAIN).  If the major coupling points
> in the Digester had been abstracted by interfaces, it would have been
> easier to insert instrumentation proxies or EasyMock'd test implementations 
> of classes at key points.

I don't know much about EasyMock, and have only rarely used

But if having an Interface rather than an abstract class makes it easier
to use these, then that's a very good point in favour of Colin Sharples'
recommendation to create Action (interface) + AbstractAction (class).
Normal code extends AbstractAction, but instrumentation code can proxy
the interface if it really needs to.

And as these uses of the interface are "transient", we don't have to
worry about "breaking" code when the interface is modified, right?

Does this satisfy your concerns?



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

View raw message