On Wed, 2005-02-02 at 06:04 -0800, Reid Pinchback wrote: > --- Oliver Zeigermann <[EMAIL PROTECTED]> wrote: > > On Wed, 02 Feb 2005 18:28:04 +1300, Simon Kitching <[EMAIL PROTECTED]> > > wrote: > > > 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 java.lang.reflect.Proxy. 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? Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
