James Carman schrieb: > On Wed, Nov 5, 2008 at 4:04 AM, Simon Kitching <[EMAIL PROTECTED]> wrote: > >> So the rule would be: >> * the project provides both an interface and an abstract class that >> implements that interface. >> * code that *uses* the API should always use just the interface, ie >> *call* methods via the interface and pass instances around as the >> interface type >> * code that *implements* the API should always subclass the base class. >> >> The project reserves the right to add methods to the interface, but will >> always provide a concrete default implementation on the abstract >> subclass. Methods will *not* be added to the interface if a sensible >> default implementation cannot be provided. >> >> > > So, perhaps I can change Proxy to use an interface rather than a > class? We already have a default implementation based on JDK proxies. > The standard JDK interface-based proxying would certainly become more useful.
One issue that the above doesn't deal with is applying the decorator pattern to such interfaces. If someone wants to decorate an existing implementation by intercepting one or more methods, then they certainly can do so by using dynamic proxying (via commons-proxy or similar), as the type is now an interface. If someone wants to hand-write a decorator class, though, then they are in trouble as the abstract base class won't help there and the project reserves the right to extend the interface. I suppose the project could *also* provide an abstract "delegator" class for each interface that simply delegates all methods. That's then *two* abstract classes for each interface though, which is getting a little clumsy. Or we could simply say "get with the modern world and use a dynamic proxy"... Regards, Simon -- -- Emails in "mixed" posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
