On Wed, 2005-02-02 at 15:04 +1300, Sharples, Colin wrote: > > > - 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.
Interesting. Extending an interface by adding methods causes source and binary incompatibility with all *implementers* of the interface, but not with *users* of the interface. So it is not a problem if classes like SAXHandler reference Action; user subclasses will still work fine with the new interface [1]. [1] Though if they override methods that have been modified in SAXHandler to *use* the new methods, then things might get hairy... 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. Nevertheless, there are definite benefits to following a standard convention... > > * yes, the name Action is quite overused. Not that I can think of a better > alternative... ;-) Yep :-( Rule is at least different - but unfortunately can be misleading. A tough choice.. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
