AOP

From APIDesign

(Difference between revisions)
Jump to: navigation, search
Line 4: Line 4:
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.
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, [[annotation]]s (they are solution for everything, as this is [[TheYearOfAnnotations2009]]). If I want to apply the asynchronous aspect to my class, I shall be able to write just:
 +
 +
<source lang="java">
 +
@Asynchronous
 +
class MyClass {
 +
public void oneMethod() { ... }
 +
public void sndMethod() { ... }
 +
}
 +
</source>
 +
 +
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 [[annotation]]s. [[Annotation]]s can have parameters. Probably (with the help of [[AnnotationProcessor]]s) one does not need any special compiler. Using [[JavaC]] is enough. In short, this is the [[cluelessness|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 [[cluelessness|clueless]].
 +
 +
== Annotations + [[AOP]] ==

Revision as of 20:48, 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, 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.

Annotations + AOP

Retrieved from "http://wiki.apidesign.org/wiki/AOP"
Personal tools
buy