RE: [aspectj-users] Drawbacks of AOP

["Marc Tremblay" <marc@xxxxxxxxxxxxx>]

> 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
> transaction aware programs, I have seen there is code like this (in plent
> places):
>
> public void foo(){
>     TransactionManager.startTransaction();
>     try{
>        //original code of foo
>     }catch(RuntimeException ex){
>       TransactionManager.abort();
>       throw ex;
>     }
>     TransactionManager.commit();
> }
>
> 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.

> > 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.

-- Marc