commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sharples, Colin" <>
Subject RE: [digester] initial code for Digester2.0
Date Wed, 02 Feb 2005 02:04:46 GMT
> > - Why is Action an abstract class?
> So that we can later add new functionality to Action without breaking
> custom Action subclasses that users have written. As long as we can
> provide a suitable default implementation in the Action 
> abstract class,
> everything runs smoothly.
> One example is the "bodySegment" callback that is now in Action. In
> Digester 1.x we could not have added this to Rule without breaking all
> custom Rule classes. But if digester2.0 had been released 
> without it, we
> could have added it later with no source or binary compatibility
> problems.
> Of course because of Java's single-inheritance policy, it would be
> impossible for a class to extend both Action and some other class. But
> (a) this is extremely unlikely, and (b) using an "adapter" class works
> around this anyway if it absolutely has to be done.

I prefer interface + default abstract implementation, the way Swing provides e.g. Action*
and AbstractAction. That way a class can still implement the interface even if it extends
from something else, and use a delegate to implement the interface. You can still evolve the
interface without breaking existing classes that extend the abstract class. Of course, there
is nothing to force people to extend the abstract class, but you can make it clear in the
doco for the interface that not to extend the abstract class is an explicit design choice
that may have dire consequences.

* yes, the name Action is quite overused. Not that I can think of a better alternative...

Colin Sharples
IBM Advisory IT Specialist
Mobile: +64 21 402 085

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

View raw message