From: Kev Jackson <kevin.jackson@...>
Date: 2006-03-31T12:43:15+09:00
Subject: Re: Ruby and AOP

James Herdman wrote:

> I'm reading "The Pragmattic Programmer" right now and I'm at the part 
> about orthogonality.  The authors mention AOP and give an example 
> involving log writing wherein you can "weave in" some AOP ("Aspect 
> Oriented Programming" for those not in the know) sexiness and log 
> writing occurs (the converse behaves as you might expect)**.
>
It's actually pretty much like this with aspectj (in java land).  I 
haven't used anything except vanilla aspectj, the new version is 
combined with AspectWorkz and uses @Annotation style java - something 
that so far I've not gotten into

> It seems to me that this behavior is *sort* of like a mixin -- i.e. 
> you can mix it in for a new behavior.  However, AOP code seems to be 
> triggered when certain actions happen.
>
It's not like a mixin in implementation

> Does this sound roughly correct to those who have AOP experience?  
> Have any of you used AOP in your experience, and if so, where has it 
> been most beneficial?

The proto-typical use case for AOP is logging, indeed the AspectJ team 
did a presentation where they demonstrated how much cleaner Apache 
Tomcat could be with an AOP approach towards logging - it's quite an 
eye-opener how much code can be replaced by a single aspect.  It's all 
good in theory, but in practice (again in java land), the tools are 
slightly different ajc instead of javac, decding on runtime or loadtime 
weaving etc etc.  Basically if you're already bogged down with 
frameworks from hell (I'm looking at you JSF), then adding AspectJ/AOP 
in can be an extra thing to try and keep straight.

That said, you can achieve some wonderful results.  I added an auditing 
feature to a project where all methods that changed the state of data 
caused an aspect to fire and to record the persons name/change etc with 
a single aspect (>100 lines of Java/AspectJ) - this made the code much 
cleaner as we didn't have calls to an audit service before executing the 
business logic, we just let the aspect take care of that.  I've also 
used it for security/authentication, again ensure the user is logged in 
before performing an action - another (relatively) straightforward aspect.

One thing I've seen but never coded up is using aspects for caching (the 
example used JBoss cache and I didn't have the willpower to download yet 
another app server just to test something)

So erm, yeah aspects are quite cool, certainly worth looking at for a 
set of problems.  IOC sort of stole their thunder and has negated the 
press AOP was getting for a while, but now most IOC frameworks use 
aspects internally.

Kev