On Wed, 02 Feb 2005 18:28:04 +1300, Simon Kitching <[EMAIL PROTECTED]> wrote:
> 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...
I am +1 for using an interface and the default (why abstract?)
implementation like with Swing or SAX. Adding new (non-abstract) call
back methods later is restricted to additional ones onyway. You can
not replace methods or their semantics. Because of this you could
easily later (after 2.0) add something like
interface ExtendedAction extends Action {
... bodySegment(...);
}
class DefaultAction implements ExtendedAction {... }
which used to be
class DefaultAction implements Action {... }
and no existing code would break, but people would be free to use the
new, extended version.
I do not agree with people being asked to extend the default
implementation only as this would make the interface obsolete. But
with the stuff I tried to sketch above it should not be possible.
Hope this makes my point clear,
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
