AOP

From APIDesign

Revision as of 21:04, 12 November 2009

Aspect Oriented Programming can be analyzed from various angles. Official explanation is available at wikipedia. This page offers my own thoughts.

Bytecode patching

There used to be a time when people went nuts on hearing the phrase bytecode manipulation. That's no longer the case. People aren't afraid to execute bytecode different to that produced by the Java compiler anymore. However, if you tell them to go directly into the .class file and manipulate the bits, the fear returns. Why is that? I believe this is due to AOP. AOP make bytecode changes normal, without requiring understanding of the class file format. In fact, AOP can be seen as a high level language for bytecode manipulation. It is not as powerful as making changes to the .class file directly, yet it is approachable to the masses and generally understandable. This perfectly illustrates the principle that good abstractions make everything more usable. The principle is true in the world of bytecode manipulation as well as in that of API design.

Hard too use

If direct manipulation of bytecode is like writing something in assembly language, then AOP is like programming in C. Quite easier, but still not supporting cluelessness enough. It is fine I can write an aspect with pointcut that executes all methods in my classes asynchronously, however to do that I need to understand a lot. I need to know how to declare a pointcut, how to describe what exactly it shall match and also how my aspect gets merged into the affected object. Quite a lot of knowledge. There has to be something simpler, if this kind of programming shall be used by masses!

Annotations

What can be simpler? Of course, annotations (they are solution for everything these days, as this is TheYearOfAnnotations2009). If I want to apply the asynchronous aspect to my class, I shall be able to write just:

@Asynchronous
class MyClass {
   public void oneMethod() { ... }
   public void sndMethod() { ... }
}

and the annotation shall do the rest. Why is this simpler? First of all everything remains in one place, one does not need to switch to .aspect file and use different language. Code completion works for annotations. Annotations can have parameters. Probably (with the help of AnnotationProcessors) one does not need any special compiler. Using JavaC is enough. In short, this is the clueless solution end users want.

Actually this is also solution taken by some projects (Lombok comes to my mind). This is find for end users, however try to write your own annotation! Hard, quite hard. You do not need to directly manipulate with bytecode, but you need to manipulate with abstract syntax trees used by compiler. That is not much simpler and definitely not clueless.

Harmony

Of course, there is much more people using these annotations than writing their own. Still writing own shall be simplified. How? Via AOP! If there was an easy way to connect annotation with an aspect (for example .aspect file), one could get benefits of both worlds - end users would have all the comfort of [annotation]]s and providers could use higher level language to define what an annotation is supposed to mean.

This is well balanced path that maximizes cluelessness of all parties. As such it qualifies for Good Technology classification. I have seen a demonstration of PostSharp for .Net recently. It provides this kind of perfect harmony between users (via annotations) and aspect developers. When I saw it I was amazed. This is how AOP shall look like! Does anyone knows is there actually is some framework in Java that work in such way?

<comments/>