"considering interceptors as aop is not 100% correct." Agreed, I would (and did in the first draft of my article) say that MethodInterceptors provide a rudimentary form of AOP. In general, though, you're correct (again) that AOP is far more robust than MethodInterceptors alone. MethodInterceptors don't allow you to introduce variables or cause a class to implement a new interface, etc. But, as you pointed out, there is a learning curve with AOP, in that you have to learn how to define pointcuts and you have to develop a new understanding of AOP in general. If I can get by without having to teach my team these concepts, then I will.
-----Original Message----- From: Alexandru Popescu [mailto:[EMAIL PROTECTED] Sent: Friday, July 29, 2005 6:03 PM To: [email protected] Subject: Re: Hivemind + AOP : Which approach to take? #: by James Carman's words the mind was *winged* :# > I would have to say that I believe in the KISS (keep it simple, stupid) > principle. Proxies are just fine in many cases. The performance costs of > proxies vs. "weaving" are negligible compared to what the methods are > already doing, for the most part. Now, if you do run into a situation where > the proxies are just too darned slow for you, then you can tweak the system > by using a different approach AOP or runtime class generation (CGLIB or > Javassist). I would venture to say that you probably won't need to do it. > In other words, YAGNI. Don't get me wrong, I do like AOP for certain tasks, > but when a framework such as HiveMind gives you a simplified solution (like > MethodInterceptors), why not use it? > Sorry I have been understood this way. I was not advocating against Hivemind, Spring or some other aop solutions. To me the initial post seemed to be a research for an intro in aop. From this point of view I considered some clarifications were needed. However, the KISS principle is here applied only to the framework development, as from my point of view the users are required to in both situations to learn only the pointcut definition language (I wouldn't bring into discussion a few interfaces API that are used in AW or AJ f.e.). As regards the fact that proxy solutions are covering many cases I agree with you. But I usually tend to use cleaner befores and afters, instead of always using arounds. I don't want to start a flame, but considering interceptors as aop is not 100% correct. Interceptors were introduced as a pattern, that at the point of aop concepts implementation seemed appropriate to be used. You can do with them some of the things you are doing with aop, but that's all. Sorry if i sound kinnda `religious´ about it :-). :alex |.::the_mindstorm::.| > > -----Original Message----- > From: Alexandru Popescu [mailto:[EMAIL PROTECTED] > Sent: Friday, July 29, 2005 5:35 PM > To: [email protected] > Subject: Re: Hivemind + AOP : Which approach to take? > > #: by Vinicius Carvalho's words the mind was *winged* :# >> In reply for James: >> Haven't tried yet, promise I'll try over the weekend. And BTW Thanks a >> lot for the post. >> >> Alexandru: >> >> "You can do offline weaving so there is no need for special >> classloaders." My mistake, I'm so sorry for that, did not know about >> that feature :D >> I found some annoying problems with Annotations and eclipse plugin as well > :( >> > > I have to agree that the plugin is not our powerfull point :-s. I would be > interested to hear what > problems have you faced with Annotations. > >> I think it's my fault the definition of intrusive on the email >> context. As you can see by my name and grammar (English is not my >> native language :P). What I'd like to say is: I prefer proxy based >> once your original code is preserved, you don't need to re-compile it >> to add/remove features from your aspects. >> > > Unfortunately, the proxy based solution is not something I would recommend > to anyone. It is a very > easy approach (look how many so called aop solutions based on proxies are > out-there, compaired with > real aop solutions) and you are loosing some of the features (f.e. static > typing) which will finally > influence the performance. But this is quite another story. > >> Not justifying my mistakes, just making them clear :P >> > > No problem. For myself it is quite the same: English is not my mother > language :-). > > take care, > :alex |.::the_mindstorm::.| > >> Thanks all >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
