A Tour of AOP
Dynamic languages have recently gained popularity and rightly so. Especially when combined with frameworks based on the languages, they can provide powerful solutions for a set of problems. For example, Ruby when combined with Rails or Groovy when combined with Grails provide simpler solutions for certain kinds of web applications. Each dynamic language offers a meta-programming facility that allows modifying the structure and behavior of a program during its execution. The meta-programming facility may modularize the advice portion of a crosscutting concern. For example, you may modify an existing method’s implementation to wrap it with code that performs the crosscutting functionality before or after dispatching the original method.
While meta-programming is a fine tool for dealing with crosscutting concerns, there are a few considerations. First, such usage requires switching to a dynamic language. The static vs. dynamic languages “war” hasn’t been concluded yet, nor it will be concluded anytime soon. So you will have to make a considered choice here. Second, meta-programming may be too powerful a tool for many programmers and a more disciplined approach might be more appropriate. Third, due to its constrained expression power, it is probably easier to create AOP tooling that helps in understanding the crosscutting structure. Such tooling is difficult to imagine with general-purpose meta-programming facilities offered by dynamic languages.
This is a reason why Dean Wampler, a long-time AOP expert, started a project to bring AOP to Ruby through the Aquarium project (http://aquarium.rubyforge.org). It shows that, while AOP is popular in statically-typed languages, it has a role to play even in dynamically-typed languages. Interestingly, as seen from this project, it is relatively easy to build AOP capabilities on the top of core meta-programming support provided by the underlying language. By providing an aspect-focused DSL to express pointcuts, Aquarium provides a solution to modularize the pointcut portion of AOP in Ruby.
It is instructive to note that the father of AOP, Gregor Kiczales, wrote the “The Art of the Metaobject Protocol (The MIT Press, 1991)” book. He clearly knows meta-programming! He still thought that AOP is better suited for crosscutting concerns and a direct application of meta-programming.
In a way, statically typed languages use AOP on the way to more comprehensive meta-programming support in order to break free from the limitations posed by the language, whereas dynamic languages benefit from AOP as a “disciplined” application of meta-programming.