AOP
From APIDesign
(→Harmony) |
(→Harmony) |
||
Line 29: | Line 29: | ||
Of course, there is much more people using these [[annotation]]s 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 fully deserve [[Good Technology]] name. This is the style majority of us will code in short future. Old [[AOP]] is dead, long live [[annotation]] based [[AOP]]! | Of course, there is much more people using these [[annotation]]s 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 fully deserve [[Good Technology]] name. This is the style majority of us will code in short future. Old [[AOP]] is dead, long live [[annotation]] based [[AOP]]! | ||
- | I have seen a demonstration of [http://www.postsharp.org/ PostSharp] for .Net recently. It provides this kind of perfect harmony between users (via [[annotation]]s) and aspect developers. When I saw it I was amazed. This is how [[AOP]] shall look like! Does anyone knows | + | I have seen a demonstration of [http://www.postsharp.org/ PostSharp] for .Net recently. It provides this kind of perfect harmony between users (via [[annotation]]s) and aspect developers. When I saw it I was amazed. This is how [[AOP]] shall look like! Does anyone knows if there actually is some framework in [[Java]] that work in this way? |
<comments/> | <comments/> |
Revision as of 21:09, 12 November 2009
Aspect Oriented Programming can be analyzed from various angles. Official explanation is available at wikipedia. This page offers my own thoughts.
Contents |
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 fine enough 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 annotations 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 fully deserve Good Technology name. This is the style majority of us will code in short future. Old AOP is dead, long live annotation based AOP!
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 if there actually is some framework in Java that work in this way?
<comments/>