Aspects of AOP
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 aquariumOr the source:
svn checkout svn://rubyforge.org/var/svn/aquarium/trunk aquarium_trunkWhat is AOP?
AOP is an effective technique for modularizing crosscutting concerns^aop_europe_conference. 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^aquarium:
- 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 => :newPointcut
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^dean_wampler.
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^dean_wampler.
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.