Die objektorientierte Programmierung ist weit verbreitet, hat aber sicher nicht alle an sie gestellten Erwartungen erfüllt. Mit ihren Abstraktionsmöglichkeiten ermöglicht sie es den Entwicklern, einen Teil der inhärenten Komplexität heutiger Applikationen mit den neuen Sprachmitteln zu bewältigen. Das Konzept von Klassen, die Verhalten voneinander erben können, erleichtert die Modularisierung und Wiederverwendung von Programmcode.
Es zeigt sich jedoch, dass dem Versuch Grenzen gesetzt sind, den Programmcode allein über das Klassenkonzept und die damit gegebenen Möglichkeiten zu modularisieren. Dies gilt besonders für das Bestreben, unterschiedliche Konzepte innerhalb einer Applikation möglichst gut voneinander zu trennen (separation of concerns): Entweder steigt die Komplexität des Designs übertrieben an, oder die Entwickler nehmen die Vermengung von Konzepten in Form einer starken Code-Fragmentierung in Kauf. Zu den Aufgaben, die sich schlecht in einem Modul kapseln lassen, gehören insbesondere technische Anforderungen wie das Schreiben von Logging-Dateien, das Fehler-Management oder die Überprüfung von Autorisierungen. Man bezeichnet solche logisch zusammengehörenden Konzepte, die sich mit den traditionellen Mitteln nicht lokalisieren lassen, als querschnittliche Belange (Cross-cutting Concerns). Als konkretes Beispiel für einen typischen Cross-cutting Concern sei die Überprüfung von Berechtigungen für alle Aufrufe von Geschäftsmethoden angeführt. Kann oder will man hier nicht auf die Hilfe eines Containers (zum Beispiel auf einen J2EE-Applikationsserver) zurückgreifen, so ist man gezwungen, jede einzelne Methode um den Code für die Autorisierungsprüfung zu erweitern. Diese Redundanz kann sehr schnell zu Inkonsistenzen führen, weil etwa für einzelne Methoden die Überprüfung vergessen wurde oder sich die Art der Überprüfung in den Methoden unterscheidet.
Aspektorientierte Programmiersprachen ermöglichen es, die querschnittlichen Belange in Form von sogenannten Aspekten ähnlich einfach zu lokalisieren, wie dies für alle anderen Belange durch die klassischen Mittel möglich ist. So, wie die objektorientierten Programmiersprachen Klassen und Vererbung zusätzlich zu den schon bekannten Sprachmitteln eingeführt haben, erweitern auch die aspektorientierten Programmiersprachen die bisherigen sprachlichen Möglichkeiten. Je nach der konkreten Implementation unterscheiden sich diese neuen Sprachmittel leicht. In irgendeiner Form ermöglichen es jedoch alle aspektorientierten Sprachen, an bestimmten statischen Punkten im Programmcode oder sogar an bestimmten dynamischen Punkten während der Ausführung des Programms zusätzlichen Programmcode aufzurufen. Dieser zusätzliche Programmcode, zusammen mit der Spezifikation, an welchen Stellen er eingefügt werden soll, wird Aspekt genannt.
Für die Verknüpfung des konventionellen Codes mit dem Code aus dem Aspekt ist ein sogenannter Weaver zuständig. Je nach gewählter Programmiersprache erfolgt die Verknüpfung dabei zur Entwicklungszeit (zum Beispiel über den Compiler) oder erst zur Laufzeit der Applikation. Indem die Aspekte die Methoden um zusätzliche Anweisungen erweitern, durchbrechen sie die Kapselung der veränderten Klassen. Der Compiler sorgt dafür, dass dies in einer wohlgeordneten und nachvollziehbaren Weise geschieht, die unerwünschte Nebeneffekte ausschliesst. Bei der als Beispiel angeführten Autorisierungsüberprüfung kann ein entsprechender Aspekt alle Geschäftsmethoden um ein im Aspekt einmalig definiertes Codesegment erweitern, das anhand der konkreten Methode und dem aktuellen Benutzer die Berechtigung überprüft. Da der Aspekt die einzelnen Geschäftsmethoden nicht explizit auflistet, sondern nur an Hand von eindeutigen Merkmalen beschreibt, wirkt er sich auch automatisch auf Geschäftsmethoden aus, die zu einem späteren Zeitpunkt eingeführt werden.
Lange Jahre waren aspektorientierte Programmiersprachen vorwiegend ein Gegenstand der Forschung; in der industriellen Entwicklung traf man sie kaum an. Aufgrund der nunmehr ausgereiften Sprachstandards und deren Implementierungen sowie dank guter Unterstützung durch moderne Entwicklungswerkzeuge finden diese Sprachen jedoch vermehrt Eingang in die Praxis. Dies zeigt sich nicht nur an der Präsenz entsprechender Beiträge in Fachzeitschriften und auf Konferenzen, sondern auch an der Verfügbarkeit von Softwarebibliotheken, die auf diesen Sprachen aufbauen.
Der Umstieg auf eine aspektorientierte Erweiterung einer konventionellen Programmiersprache (beispielsweise von Java auf AspectJ) darf auf keinen Fall unterschätzt werden. Die Schwierigkeiten durch den Paradigmenwechsel sind ähnlich gross wie die beim Umstieg von einer prozeduralen Programmiersprache auf eine objektorientierte. Aspektorientierte Sprachen erlauben jedoch eine schrittweise Adaption. So können in einer ersten Phase Aspekte nur zur Entwicklungszeit als Diagnose- und Entwicklungswerkzeuge zum Einsatz kommen. Der produktive Code bleibt in diesem Szenarium von den Aspekten unberührt, und es müssen auch nicht gleich alle Entwickler die aspektorientierten Erweiterungen kennen und nutzen. Sobald jedoch Aspekte Bestandteile des produktiven Applikationscode sind, sollten alle Programmierer zumindest Grundkenntnisse über die aspektorientierten Erweiterungen der eingesetzten Programmiersprache besitzen. Dies gilt auch, wenn man versucht, die Programmierung der Aspekte exklusiv durch einige wenige Entwickler durchführen und den Rest des Teams konventionell arbeiten zu lassen. Das Fazit: Die aspektorientierte Programmierung erfordert für Entwickler einiges an Umdenken, kann als Erweiterung der objektorientierten Programmierung aber einen wichtigen Beitrag bei der Erstellung anspruchsvoller Softwaresysteme liefern.
Thomas Traber (thomas.traber@ergon.ch) ist Senior Software Architect bei der Ergon Informatik.
