Why can ProxyFactory not be an abstract class? Stephen
--- James Carman <[EMAIL PROTECTED]> wrote: > Robert, > > How about this? We provide a "default" > implementation which just uses JDK > proxies. So, ReflectionProxyFactory would become > ProxyFactory and > JavassistProxyFactory and CglibProxyFactory would > just extend/override it. > That way, if we do add a method to ProxyFactory, the > subclasses don't > necessarily have to override it. The > implementations would just use > reflection rather than a more advanced proxying > technique. ProxyFactory > would actually be concrete and not abstract in that > case. Does that sound > like it would work better? Would that address your > concerns with the binary > compatibility? > > James > > -----Original Message----- > From: robert burrell donkin > [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 19, 2005 6:18 PM > To: Jakarta Commons Developers List > Subject: Re: [proxy] Moving Proxy to Commons Proper > > On Wed, 2005-10-19 at 16:35 +0200, Knut Wannheden > wrote: > > On 10/19/05, James Carman > <[EMAIL PROTECTED]> wrote: > > > > i would also like to reiterate stephen's > warning: if you use > interfaces, > > > > be very sure that you are not going to need to > change them in any > > > > fashion. i would very strongly suggest > implementing the key > > > > ProxyFactory logical interface as an abstract > class. this isn't bias > (i > > > > love interfaces when coding applications) but > a hard lesson painfully > > > > learnt. > > > > > > Robert, > > > > > > I understand the concerns here, but I am really > torn between changing > the > > > API and leaving it like it is. IMHO, it is > *very* unlikely that a user > of > > > Commons Proxy is even going to implement > ProxyFactory on their own. If > I > > > had to ballpark it, I would be surprised if 1 > out of every 100 (I might > even > > > go 1000) people who use Commons Proxy implement > ProxyFactory. That's > the > > > whole point of using Commons Proxy in the first > place. You don't have > to > > > write the proxying logic yourself! So, what is > our target here? Are we > > > looking for 100% backward compatibility with > *all* projects? Or, are we > > > happy with keeping something more like 90% or > 95% of our users happy? > Maybe > > > we could tell them in the documentation that if > they have a proxying > > > technology that they wish Commons Proxy > supported that they can submit a > > > request to the mailing list or into Bugzilla for > it and we can take care > of > > > it (of course, any code that gets us going would > help). As long as we > > > decide between AOP Alliance vs. "rolling our > own" interfaces, I'm pretty > > > happy with the ProxyFactory interface. Besides, > there's really nothing > you > > > can't do with Invokers. That's sort of the > "common denominator." > > > > > > > In Eclipse APIs it is common practice that > interfaces are never > > changed -- hence new interfaces have to be added > when new changes are > > required -- and abstract classes are used where > changes (in form of > > new methods) are expected (see > > > http://www.artima.com/lejava/articles/designprinciples.html). > > > > As you say the Invokers are the "common > denominator". So ProxyFactory > > could be implemented as an abstract base class > with the > > createInvokerProxy() method declared as abstract > and the other proxy > > factory methods defined in terms of that. Concrete > implementaions > > would although do best in overriding these other > methods for > > performance reasons. > > > > Although, as you say, there are probably not many > users who will want > > to implement this interface anyways. So maybe it's > best left as it is. > > > > I'm torn on this one. Any other thoughs? > > there are certain pitfalls associated with deep > libraries that are not > commonly found elsewhere and are therefore not > generally well known > amongst other communities. (by deep libraries, i > mean libraries that are > used by libraries rather than applications.) these > issues don't really > effect applications or frameworks. > > we often talk about two different forms of > compatibility: semantic and > binary. binary compatibility is defined by the java > language and > concerns when one version of a class can be > substitute for another. > semantic compatibility means that existing uses > don't break when one > version of a class is substituted for another. > > when developing a deep library, compatibility is big > issue. since the > library will be used by many other libraries and so > indirectly by many, > many applications, breaking compatibility means > disrupting many users > who were not aware that they even used your library. > this will make you > very personally unpopular. due to the number of end > users who may be > effected by changes in semantics, breaking semantic > compatibility is > quite a big deal. so, it's usually better to choose > delegation and > logical interfaces over subclassing frameworks. > > breaking binary compatibility is a very big deal for > deep libraries. by > breaking binary compatibility, all users must be > forced to choose to > have only one version of the library on the > classpath. if a user is > building an application and require two libraries > each of which depends > on a different version of your library, this will > cause them great pain > resulting in great anger. > > the problem with interfaces is that adding methods > breaks binary > compatibility. > > some of the commmons components are amazingly widely > distributed. proxy > is just starting out but in a year or two, maybe > it'll be relied upon by > hundreds of open source libraries (as several of the > deep commons > libraries are). now, imagine having to justify > yourself to all those > downstream users who use those libraries why you > needed to break binary > compatibility: this kind of thing really trashes > your reputation and the > reputation of your component as well as upsetting > all those downstream > users who'd never even heard of your library before. > > but, this choice is yours. this is just advice and > not a condition :) > > - robert > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > === message truncated === --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
