RE: [aspectj-users] Question on architectural aspects

["Gregor Kiczales" <gregor@xxxxxxxxx>]

Aspects are good for both large scale crosscutting concerns, what
you are calling 'system side', and small scale, in just a few or
even one class. They are good when they help you modularize some
concern that you want to modularize.

AspectJ isn't trying to stop you from using an aspect that just
affects one class. In fact it supports inner aspects, and static
inner aspects for just that reason.

Sometimes there are elements of 'business logic' that are crosscutting
concerns, and they make sense for aspects. The books and various tutorials
that are around show good examples of this. If you want something easy to
get in hardcopy, consider Ramnivas's book.

But a key point is that good use of aspects should make the code easier
to understand, not harder. So do use some finesse, don't do something
with aspects just because it is cool. Do it because it makes what is
going on in the code more clear and more modular.

I believe topics about AspectJ style are quite suitable for this list.

If you post some concrete examples more detailed stylistic issues could be
debated. 



> -----Original Message-----
> From: aspectj-users-admin@xxxxxxxxxxx 
> [mailto:aspectj-users-admin@xxxxxxxxxxx] On Behalf Of Russell Miles
> Sent: Tuesday, December 02, 2003 4:22 AM
> To: aspectj-users@xxxxxxxxxxx
> Subject: [aspectj-users] Question on architectural aspects
> 
> 
> Hi everyone,
> 
> Hopefully this isn't an off-topic question, but if it is as 
> it it not very AspectJ technical in nature then please let me 
> know where else I can ask it. I am looking at the recent 
> example on this list of using aspects to provide a default 
> implementation to a method on an interface (I think this is 
> in Ramnivas' book). I'm worried about the knock on effects 
> this could have on a design, the worst case being the 
> apparent possibility of getting a diamond shape multiple 
> inheritance issue ? Maybe I'm not understanding the example, 
> but I got all excited when I first saw it earlier on this 
> list but then the more I thought about it the more concerned I got.
> 
> I think my problem stems from questions over whether or not 
> aspects are best applied as 'system side' cross cutting 
> concerns or potentially on the much smaller class only scale? 
> I can definitely see the advantages for using aspects on the 
> small scale in terms of the clever things that can be done, 
> but isn't that getting awfully close to using aspects to do 
> clever things that the language is specifically attempting to 
> prevent us from doing? 
> 
> I always understood the more system level selling point for 
> applying aspect concerns across the big picture, but when 
> aspects start to seriously affect the underlying architecture 
> of the business logic I get worried as I feel that one of the 
> rules of aspect orientation is to apply aspects to business 
> logic, not define the business logic itself in aspects. I 
> guess the rule I tend to use is develop the application using 
> good OO and patterns, identifying cross cutting concerns for 
> the aspects to be developed for, and then bring both parts 
> together ... but the business logic still makes sense to me 
> in plain OO. 
> 
> I guess I'm not clearly seeing the advantages of applying 
> aspects on a class by class basis, or to invoke architectural 
> decisions such as OO patterns, but I am definitely seeing 
> worrying problems where developers are going to be coming to 
> new applications and are going to find it increasingly 
> difficult to understand the business logic as it is being 
> applied using aspects.
> 
> I know this is not a technical AspectJ question, and I 
> apologise once again if this is the wrong place, but this 
> discussion is killing me at work with my OO people and I'm 
> desperate to fully understand the motivations behind aspects 
> being used on the small scale.
> 
> Cheers
> 
> Russ Miles
> 
> <Never any offence intended>
> 
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
>