Bamboo Blog - Aspects of AOP

Aspects of AOP matt

October 9th, 2007

Having worked on AspectJ Development Tools (AJDT) a while back, I thought aspect-orientated programming (AOP) would be good topic for my Talk@2. I’m not going to go into too much depth but hopefully it’ll highlight some of the possible uses of AOP.

A bit of history

AOP started out with AspectJ from Xerox PARC about 10 years ago, and is now an open source project managed by the Eclipse Foundation. AspectJ is an extension to Java that adds aspect-orientated capabilities, while not the only implementation of AOP it’s practically the de facto in the Java camp.

But what about Ruby? There are a few AOP Frameworks for Ruby AspectR (hasn’t been updated in a while) and Aquarium.

I use Aquarium later in the examples, you can get it with:

sudo gem install aquarium

Or the source:

svn checkout svn://rubyforge.org/var/svn/aquarium/trunk aquarium_trunk

What is AOP?

AOP is an effective technique for modularizing crosscutting concerns¹. Crosscutting concerns appear all over the place in applications such as, authentication, logging, caching etc. But why is this a problem? Current implementations of cross cutting concerns break modularization and can lead to spaghetti code, which is hard to maintain.

AOP to the rescue! With AOP concerns that crosscut many classes are modularized into an aspect. This allows you to write a logging aspect (for example), which can effect your entire application, a group of classes or just a single method.

What is an aspect?

It describes how code for a concern should be integrated into the code for the whole application, without modifying the original code

In AspectJ the java bytecode is manipulated to include the code from the aspects before, after or around the specified method calls. But in Ruby it’s done using the meta-programming mechanisms available.

Aspects comprise of²:

Join Points: A point of execution in a program where ‘advice’ might be invoked. 
Pointcuts: A set of join points of interest, like a query over all join points in the system.
Advice: The behavior invoked at a join point.

There are a few types of advice available. Before advice executes code before the join point, after advice does so after returning from the join point and around advise ‘wraps’ a join point.

Here are some examples of Aquarium code, but for more detailed examples see the example page

Join Point

JoinPoint.new :type => Post, :method => :new

JoinPoint.new :object => @post, :method => :new

Pointcut

Pointcut.new  :types => UsersController, 
  :methods => [:edit, :update, :destroy, :admin]

Before Advise

include Aquarium::Aspects::DSL::AspectDSL 

before :pointcut => your_point_cut do |jp, *args| 
  log “Entering: #{jp.inspect}” 
end

Isn’t AOP just meta-programming?

Meta-programming can support the essence of AOP, and can also support lots of other things that fall out of the scope of AOP. Ruby can achieve the functionality that AOP provides through meta-programming, why should I use a framework?

AOP frameworks provide another level of abstraction, a nice API (Domain Specific Language) to express crosscutting concerns intuitively.

AOP vs Design Patterns

Design Patterns are templates for solving certain problems, many of which could be implemented better with AOP. As mentioned aspects modularize the concern for a problem. So you can reuse aspects in other applications unlike design patterns which have to be implemented each time.

Soon AOP will be the de-facto implementation for cross cutting concerns, just as Object-oriented programming is for inheritance, encapsulation etc.

It should be made clear that AOP isn’t a Redpill! You don’t gain extra functionality, but AOP make implementing the solutions to these problems easier, cleaner and is closer to God³.

AOP and Rails?

Rails has filters so why should I bother with AOP? Rails filters use method aliasing and Aquarium does basically the same thing, with a little more sophistication to make it more reliable to add multiple “filters” or to remove any one of them dynamically.

Also plugins that override method_missing can step on each other and behave in unexpected ways. With AOP we can overcome this problem.

There are roughly 180 cases of method aliasing in the Rails 1.2 stack, much of which would be cleaner and more robust if implemented as advice, instead³.

AOP isn’t the future

It’s here NOW! The Spring Framework is built on top of AspectJ and is a popular Java/JEE application framework.

There are some AOP features penned for Ruby 2.0, such as :pre, :post, and :wrap for methods.

Where I see a possibility AOP adoption starting out is with non obtrusive (orthogonal) aspects for logging, tracing, etc. After people get comfortable with AOP, then we’ll start to see the real power of AOP being utilized within business objects.

So there you have it a quick round up of AOP, when I get some time I might have a crack at using Rails and Aquarium to make a demo app or plugin.

References

¹ Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, OCP. C., Loingtier, J. and Irwin, J., Aspect-oriented programming. European Conference on Object-Oriented Programming (ECOOP), 1997, 220-242.

² Aquarium

³ Correspondence with Dean Wampler