Re: RE: [aspectj-users] Drawbacks of AOP

["Dale Asberry" <lists@xxxxxxxxxxxxxxx>]

   >  > On Thursday 17 April 2003 19:24, Marc Tremblay wrote:
   >  > > I think further to this, a method has a certain contract to fulfill, and it
   >  > > should in no way rely on aspects to fulfill that contract.  Nor should
   >  > > aspects be allowed to change the contract.
   >  >
   >  > I definitifly disagree here. Transaction handling is a counterexample.
   >  > Transaction handling is definitifly a crosscutting concern. In quite a lot of
...
   >  >
   >  > All the transaction handling code should be moved to an aspect.
   >  > And Transactionhandling does definitfly change some of the contract of the
   >  > methods.
   >
   >  To me this is the kind of thing that should be handled declaratively in a deployment descriptor and applied by
   >  some sort of runtime container (not nesc. EJB, but along those lines).  To me, implementing things like
   >  transaction management, security, etc. as an aspect leads to hidden complexity and thereby can render the code
   >  unmaintainable.
   >

Aspect-oriented programming IS DECLARATIVE.  However, rather than being in some vendor-specific deployment descriptor language, it is in a Java-like extension language.  This also buys you the ability to remove any impedence mismatch between your Java app that would be artificially imposed by a deployment descriptor language.

I would argue that deployment descriptors are at least equivalent in terms of hidden complexity, possibly worse considering that descriptors often times have unexpected side-effects.  With aspects, you can explicitly specify your join points and can widen or narrow each based on whether the effects are too exclusive or inclusive.  You get what you get with deployment descriptors.

   >  > > If one follows these rules,
   >  > > then it's quite irrelevant as to whether an aspect crosscuts a piece of
   >  > > code or not.  This way the code works the same everywhere...  the system as
   >  > > a whole may work differently (ie. logging behaviour is different, or we
   >  > > gain/lose resource pooling), but that has more to do with the context
   >  > > within which the code runs as opposed to the code itself.
   >  >
   >  > But this limitation is much to strict. Most of the more advanced crosscutting
   >  > concerns change the contracts of a method. e.g. security, persistency,
   >  > accesscontrol, transaction handling, encription of parameters, etc.
   >
   >  I certainly agree with you that these crosscutting concerns don't belong in the code itself, but I just think
   >  the deployment descriptor approach is a better one than using aspects.  Just because we can solve these
   >  problems with aspects, doesn't mean aspects are the best way to solve these problems.  These concerns are the
   >  kind that should be handled in a container or runtime framework in my opinion.
   >

I would disagree... I believe that these are the BEST (and most easily maintainable) ways to use aspects.  In addition, I believe that aspects are particularly adept at monitoring and changing the internal state of an object.  Instead of having 10 methods update state in similar but yet different ways, using a single aspect with only a few join points significantly simplifies your object.  It also eliminates the cut-and-paste programming problems for the "similar-but-different" pattern.  

(I apologize for not giving a more specific example, I'm somewhat "disconnected" right now.)