> > - 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 Email: [EMAIL PROTECTED] Mobile: +64 21 402 085 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
