Ruby and AOP

Ruby
1

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

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?

Thank you,

James H.

** For those interested, yes a Ruby AOP project exists:
http://aspectr.sourceforge.net/

2

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

3

Another distinction is that AspectJ and related technologies use a
“push”
approach to weave aspects into different join-points in the code. In the
case of a mixin, it’s more of a “pull” approach where you have to walk
up to
the type that you want to add the mixin functionality to.

I spent a lot of time a few years ago implementing a runtime
aspect-weaving
extension to the CLR - that had a lot of potential - you could weave
code
into the middle of a running system, and then yank it back out when you
were
done. Great for doing things like injecting diagnostic probes into a
corrupted system to perform post-mortem diagnosis.

-John

Yes, it’s like a mixin but on more than a ‘class’ level. It’s

4

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.

Pardon my naivity, but what is IOC?

Thank you,

James H.

5

On 3/30/06, James H. [email protected] wrote:

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?

Yes, it’s like a mixin but on more than a ‘class’ level. It’s
cross-cutting(to use the jargon) across class hierarchies.

Basically AOP allows a further and different separation of concerns in
a software system. Think of transactions and security as better uses
of AoP. An object should be able to participate in a transaction
without ever knowing it’s been in one. Log writing is the ‘Hello
World’ of AoP.

I’ve used AoP for Logging and exception tracing at runtime of working
systems.

Ron Bodkin and Ramnivas Laddad have excellent blogs on AoP.

hth,

6

On 3/31/06, James H. [email protected] wrote:

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.

Pardon my naivity, but what is IOC?

IOC = Inversion Of Control. See Marting Fowler’s article for a good
explanation: Inversion of Control Containers and the Dependency Injection pattern

There are several implementations in Ruby, Needle for example:
http://needle.rubyforge.org/

7

Hi,

James H. schrieb:

Pardon my naivity, but what is IOC?

Inversion of Control. Read Martin F.'s article “Inversion of Control
Containers and the Dependency Injection pattern” at

Lutz