Dabei könnte ich erstmal auf unser AOP-Training hinweisen, das diese Themen behandelt, aber solche billige Werbung erspare ich mir lieber...
Mein Kollege Adrian Colyer, der sich mittlerweile schon eine Ewigkeit mit AOP beschäftigt und zuvor z.B. an der Einführung von AOP bei IBM u.a. in den Middleware Bereich gearbeitetet hat, schägt ein Verfahren vor, wie man AOP einführen kann. Durch das Verfahren wird auch das Design-Thema klar: Er schlägt vor, als ersten Schritt Aspekte zu definieren, die bei z.B. aus Layering Gesichtspunkten heraus verbotene Operationen (siehe hier) als Compiler-Error klassifizieren. Als nächsten Schritt sieht er dann die klassischen technischen Aspekte wie Tracing, Profiling usw, die bei AspectJ auch in Development und Production Aspekte eingeteilt werden. Erst dann kommt Aspekt-orientierte Analyse und fachliche Aspekte. Zu diesem Thema hat Ivar Jacobson auch schon ein Buch geschrieben (immerhin der Erfinder der Use Cases...) und es gibt auch noch ein zweites Buch in diesem Bereich (siehe unten). Also gibt es sogar im Bereich AOP Analyse bereits publizierte Best Practices.
Diese Diskussion bezieht aber noch nicht Spring ein und durch Spring ändert sich hier nochmal einiges. Ohne AOP kann man nämlich keine nicht-triviale Spring-Applikation bauen. Security, Transactions usw. bauen alle darauf auf und es gibt auch eine breite Vielfalt an vorbereiteteten technischen Aspekten (Tracing, Performance Monitoring), die man nutzen kann. Daher ist durch Spring der erste Schritt zur Adaption von AOP die Benutzung von Spring, bei der man ohne AOP eh nicht auskommt. Das Schreiben eines eigenen Aspekts ist ebenfalls recht einfach und auch in der Online-Doku nachzulesen. Daher gibt es hier eigentlich auch keine Barriere: Spring ohne AOP macht keinen Sinn und selber Aspekte schreiben ist recht einfach. Man muss es nur tun...
Das interessante ist nun, dass man bereits mit diesen technischen Aspekten zum Teile ganze Layer einsparen kann, weil man eben Security, Transactions und auch Exception-Handling nicht mehr in jeder Klasse ausprogrammieren muss, sondern es zentral irgendwo als Aspekt macht. So gibt es Beispiele, in denen es ganze Layer gibt, die nur für die Remote Aufrufe die Themen Security, Transactions und Konvertierung der Exceptions behandeln und dabei einen signifikanten Anteil des Gesamtcodes darstellt, weil man eben für jede Remote zugreifbare Funktion nochmal dasselbe hinschreibt. Nur mit AOP oder ähnlichen Hilfsmitteln kann man das zentralisiert implementieren und das ist wirklich kein Hexenwerk. Deswegen glaube ich, dass man nur mit AOP den Don't-Repeat-Yourself-Imperativ in statisch typisierten Programmiersprachen umsetzten kann und halte AOP für eine wesentliche Basis-Technologie.
Zweifel habe ich im Bereich aspekt-orientierter Analyse. Meine Erfahrung ist, dass auch objekt-orientierte Analyse noch nicht flächendeckend eingeführt ist, so dass es fraglich ist, ob man hier schon in den Bereich Aspekt-Orientierung vorstoßen will, wenn man Objekt-Orientierung noch nicht vollständig umgesetzt hat.
Meiner Meinung nach hat man schon bei der Beschränkung von AOP auf technische Aspekte ein großes Produktivitätspotential. Diesen Bereich hat die Software-Entwicklungs-Community auch gut verstanden und setzt es spätestens seit EJB 1.0 auch so um - schließlich sind Transaktionen und Security dort als eine Art Aspekt implementiert, auch wenn niemand es damals so genannt hat und vollwertige AOP-Lösungen auch mitttlerweile wesentlich mächtiger sind.
Also schauen wir mal - immerhin bietet Spring 2.0 einen einfacher Einstieg in AspectJ, so dass Spring 2.0 die Einstiegsbarriere für AspectJ eliminiert. Bei der Popularität von Spring kann es sehr gut sein, dass dadurch auch AspectJ sich einer deutlich breiteren Benutzer-Basis erschließt.
¶ 11:51
