J and I and Me
2007-02-04
  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.
 
Bookmark and Share
Comments:
Ich denke, AOP ist einfach noch nicht Mainstream genug. Vor 10 Jahren sagten viele, dass OO zu kompliziert ist. Vor 20 Jahren war es die modulare/strukturierte Programmierung, die vielen als zu komplex erschien.

Hilfreich wäre sicherlich, wenn AOP fester Bestandteil einer Programmiersprache (Java?) werden würde. Und genauso, wie die Schwimmwagen als einfaches (und einziges ;-) ) Beispiel für Mehrfachvererbung herhalten mussten, bräuchte es einfache Beispiele (wie z.B. Logging) für AOP.
Und eventuell wäre eine einheitliche Notation für AOP hilfreich (so wie der Punkt zwischen Objekt und Instanzvariable)...

Dinge. Brauchen. Zeit.
 
Kommentar veröffentlichen

<< Home
J for Java | I for Internet, iMac, iPod and iPad | Me for me

ARCHIVES
Juni 2005 / Juli 2005 / August 2005 / September 2005 / Oktober 2005 / November 2005 / Dezember 2005 / Januar 2006 / Februar 2006 / März 2006 / April 2006 / Mai 2006 / Juni 2006 / Juli 2006 / August 2006 / September 2006 / Oktober 2006 / November 2006 / Dezember 2006 / Januar 2007 / Februar 2007 / März 2007 / April 2007 / Mai 2007 / Juni 2007 / Juli 2007 / August 2007 / September 2007 / Oktober 2007 / November 2007 / Dezember 2007 / Januar 2008 / April 2008 / Mai 2008 / Juni 2008 / August 2008 / September 2008 / November 2008 / Januar 2009 / Februar 2009 / März 2009 / April 2009 / Mai 2009 / Juni 2009 / Juli 2009 / August 2009 / September 2009 / Oktober 2009 / November 2009 / Dezember 2009 / Januar 2010 / Februar 2010 / März 2010 / April 2010 / Mai 2010 / Juli 2010 / August 2010 / Oktober 2010 / Januar 2011 / Februar 2011 / März 2011 / April 2011 / Mai 2011 / Juni 2011 / August 2011 / September 2011 / November 2011 / Februar 2012 / April 2012 / Mai 2012 / April 2013 / Mai 2013 / Juni 2013 / Januar 2015 / Juli 2015 / Februar 2016 /

Links

Twitter
Google +
Slideshare
Prezi
XING
LinkedIn
Das Spring Buch


Feeds

Feedburner


Impressum
Betreiber und Kontakt:
Eberhard Wolff
Leobschützer Strasse 22
13125 Berlin
E-Mail-Adresse: eberhard.wolff@gmail.com

Verantwortlich für journalistisch-redaktionelle Inhalte:
Eberhard Wolff