AOP ist zu kompliziert! AOP geht leider immer noch der Ruf voraus, zu kompliziert zu sein. Das Thema hatte ich schon mal am Rande aufgegriffen.

Es ist zunächst schlicht so, dass AOP eine Basis für Enterprise-Anwendungen bildet. Schon in EJB gab es Unterstützung für Security und Transaktionen und der notwendige Code wurde zwischen den Interfaces des EJBs und der Implementierung eingebaut. Das Problem bei diesem Ansatz war, dass es keine Möglichkeit gab, eigene Dinge analog zu Security und Transaktionen einzubauen. EJB 3 bietet hier zwar einen Interceptor-Mechanismus, aber der führt dazu, dass man an jeder Bean eine Konfiguration für den Interceptor vornehmen muss oder aber der Interceptor bei jeder Bean zuschlägt - dann muss man selber zum Beispiel abfragen, ob die Bean eine passende Annotation trägt.

Es geht hier also zunächst darum, eine vernünftige und allgemeingültige Basis für die Implementierung technischer Aspekte zu schaffen. Und in AOP / AspectJ sind mittlerweile 10 Jahre Forschung und Entwwicklung geflossen - was könnte also besser geeignet sein? Bei Spring ist es durch den DebugInterceptor, den PerformanceMonitoringInterceptor oder dem JamonPerformanceMonitorInterceptor hat Spring auch gleich eine Palette an anderen interessante Interceptoren.

Nun kann man natürlich argumentieren, dass das alles viel zu komplizier ist. Eine Möglichkeit damit umzugehen, ist es, dass man das Wissen auf einige Leute beschränkt. Es muss schließlich nicht jeder technische Aspekte wie Security oder Tranaktione implementieren - dann kann man das Wissen über AOP auch auf jene beschränken, die solche Aspekte implementieren wollen bzw. müssen - die anderen können einfach die richtigen Annotationen im Code setzen und sich dann darauf verlassen, dass das richtige passiert - wie es eben auch schon bei EJB war.

Der andere interessante Effekt ist, dass AOP der Ruf voraus geht, dass es kompliziert ist - und zwar bis dahin, dass Adrian Colyer zum Teil die Strategie hat "Don't tell them it's AOP". Das ist nachvollziehbar - zumal die AspectJ Pointcuts den normalen Methodendefinitionen in Java sehr ähnlich sind.

Man sehe sich folgende Beispiel an:

@Aspect
public class MeinDebugAspekt {

 @Before("execution(void tuEs())")
 public void meinBeforeAdvice() {
  System.out.println("Before Advice");
 }
}

Hier gibt es nicht viel zu verstehen, außer dass vor Ausführung (execution) jeder Methode, die die Methodendefinition void tuEs() hat, noch der zusätzliche Code aus meinBeforeAdvice ausgeführt wird. Wenn man dann noch Wildcards einführt wie

@Aspect
public class MeinDebugAspekt {

 @Before("execution(* tuEs(..))")
 public void meinBeforeAdvice() {
  System.out.println("Before Advice");
 }
}

dann kann man schon mal definieren, dass beliebige Rückgabewerte (*) und Parameter (*) für die Methode erlaubt sind - das ist dann schon ausreichend, um zum Beispiel für die create()-Methoden der DAOs einen Aspekt zu definieren.

Also: AOP ist nicht so kompliziert wie es scheint. Und selbst wenn - nicht jeder muss es verstehen - schließlich versteht auch nicht jeder die internen Abläufe in einem Application Server. Dennoch benötigt man die Technologie, um Aspekte wie Security, Transaktionen usw. zu implementieren. Und statt einer ad-hoc-Lösung ist dann AOP als etablierte Basis sicher besser.  ¶ 14:32