Aspektorientierte Programmierung

Als Aspekte bezeichnet man in der Programmierung Komponenten-übergreifende Zusammenhänge. Die aspektorientierte Programmierung (AOP) führt Aspekte als eigene syntaktische Strukturen ein und erhöht damit die Modularität von objektorientierten (OO) Programmen bezogen auf diese Aspekte.


Aspekte sind in komplexen Systemen unvermeidbar und definieren einen expliziten Verantwortungsbereich. Durch eine klare Struktur haben Aspekte eine bestimmte Menge von Methoden, die die Grenzen von Komponenten überschreiten und an bestimmten Stellen eingesetzt werden. Als Vorteil der aspektorientierten Programmierung wird die Trennung der Semantik einer Anwendung von den technischen Details wie Fehlerbehandlung, Persistenz, Validierung oder Sicherheit angesehen. Als Nachteile werden eine Erhöhung des Overheads im generierten Programmcode oder auch daraus abzuleitende Verluste in der Performance einer Anwendung genannt.

Das Konzept der aspektorientierten Programmierung

Das Konzept der aspektorientierten Programmierung basiert auf der Arbeit von Gregor Kiczales bei der Firma Xerox, Palo Alto Research Center. Dort wurde auch mit AspectJ als eine Erweiterung der Programmiersprache Java die erste aspektorientierte Sprache entwickelt, bevor deren weitere Entwicklung dann in ein Projekt der Eclipse Organisation übergeleitet wurde. Mittlerweile gibt es jedoch auch für andere Programmiersprachen wie Python, C++ oder PHP entsprechende aspektorientierte Implementierungen.

Die Zielsetzung der aspektorientierten Programmierung

Die Zielstellung der aspektorientierten Programmierung ist die klare Trennung von Komponenten und Aspekten (auch Concerns genannt). Man spricht in diesem Zusammenhang auch davon, dass Aspekte Komponenten - oder ggf. auch andere Aspekte - quer schneiden. Dabei ist eine Komponente im Sinne der AOP eine Systemeigenschaft, die in einer verallgemeinerten Prozedur gekapselt werden kann. Im Gegensatz dazu ist ein Aspekt eine Systemeigenschaft, die nicht in einer verallgemeinerten Prozedur gekapselt werden kann. Beispiele für Aspekte sind Funktionalitäten der Persistenz, der Sicherheit, der Protokollierung oder Logging-Prozeduren, die dem objektorientierten Ansatz folgend fortwährend in den einzelnen Klassen gekapselt sind. Damit liegt der Code redundant vor, und man bezeichnet dies als Code Scattering (Code Streuung). Die Verbindung von Code und Aspekten, die nichts mit der eigentlichen Aufgabe der Komponente zu tun haben, bezeichnet man dagegen als Code Tangling (gewürfelter auch ungeordneter Code). Ändern sich zum Beispiel die Anforderungen an einer dieser Aspekte so müssen alle betreffenden Klassen angepasst werden - dies widerspricht eindeutig dem Prinzip der Wiederverwendbarkeit.

Der Mechanismus der aspektorientierten Programmierung

Der Mechanismus, wie das die AOP ihn benutzt, ist im weiteren Sinne auch schon in Verbindung mit der subjektiven Programmierung bekannt. In der Literatur wird im Zusammenhang mit den Komponenten-übergreifenden Aspekten auch häufig von sogenannten Crosscutting Concerns gesprochen. In Aspektorientierten Systemen werden diese nicht separat in jede betreffende Klasse eingearbeitet sondern zunächst isoliert implementiert. Die Verbindung zum eigentlichen, anwendungsbezogenen Programmcode erfolgt automatisiert über die programmierten Aspekte. Dabei wird in dynamisches und statisches Crosscutting unterschieden. Man bezeichnet diesen Prozess der Manipulation von Klassen auch als Einweben (engl. weaving) der Aspekte in den Programmcode.

Nachfolgend werden die grundsätzlichen Vor- sowie die Nachteile der AOP zusammengestellt. Dabei werden hier zunächst nur die wesentlichen Vorteile dargestellt, ohne deren eventuelle Wechselwirkungen explizit zu betrachten:

Verantwortung. Jedem Modul ist ein klarer Verantwortungsbereich zugeordnet.

Modularisierung. Durch Vermeidung von Scattering und Tangling wird der Programmcode besser modularisiert. Dies hat zur Folge eine reduzierte Redundanz, die Erhöhung der Verständlichkeit und letztendlich eine besser zu pflegende Software. Dem Argument vom reduzierten Programmcode wird in der Literatur ebenso häufig widersprochen, auch wenn diesem Gedanken intuitiv durchaus gefolgt werden kann. Letztendlich wird die Reduzierung der Code-Redundanz jedoch wohl davon abhängig sein, wie viele Komponenten ein Aspekt "quer schneidet". Je höher die Anzahl der quer schneidenden Komponenten ist, umso mehr verstreuter Code kann reduziert werden.

Einfachheit. Architektur und Entwurf können sich auf die Anforderungen der Anwendung selbst konzentrieren. Diesem Grundsatz nach Einfachheit des Entwurfs folgt auch der Ansatz des extreme Programming.

Wiederverwendbarkeit. Aspekte sind von ihrem Ansatz weniger eng an eine Anwendung gekoppelt, als das der Fall bei einer konventionellen Programmierung ist. Daher ist aspektorientierter Code im Allgemeinen gut wiederverwendbar.

Stabilität. Dadurch dass Crosscutting Concerns bei der Implementierung weiterer anwendungsspezifischer Funktionalität weniger schnell übersehen werden, wird der Code insgesamt stabiler.

Kosten. Einfachheit, Wiederverwendbarkeit und Stabilität wirken sich nachhaltig positiv auf die Kosten aus. Zudem kann das System früher genutzt werden, und damit amortisieren sich auch die Kosten der Entwicklung früher.

Diesen Vorteilen stehen aber auch durchaus Praxis-bezogene Nachteile gegenüber:

Debugging. Aufgrund der Trennung von Code- und Prozessstrukur kann dem Kontrollfluss in einem Programm nur mit Schwierigkeiten gefolgt werden. Die Problemstellung ist vergleichbar mit der dynamischen Bindung in der objektorientierten Programmierung. Performance. Beim Weben zur Laufzeit (dynamisches Weaving) sind Reduzierungen in der Performance nachzuvollziehen. Beim statischen Weaving sind diese nur in eingeschränktem Maße zu realisieren.

Kapselung. Durch die AOP wird das objektorientierte Prinzip der Kapselung gebrochen, da eine Klasse nicht mehr ihr gesamtes Verhalten unter eigener Kontrolle hat.

Kopplung. Sogenannte Pointcuts werden überwiegend über Namen von Klassen, Methoden, Variablen oder auch Paketen definiert. Das hat eine Kopplung von Komponenten und Aspekten zur Folge und führt u.a. zur Forderung nach einer strikten Einhaltung von Namenskonventionen.

Disziplin. Die Anwendung der AOP setzt die Einhaltung von Software-Standards nicht nur im Hinblick auf Namenskonventionen voraus, was in größeren Entwicklungsteams u. U. mit Schwierigkeiten verbunden ist.

Die Begriffswelt der AOP ist zum Teil unterschiedlich geprägt - beispielsweise werden häufig "nicht funktionale Anforderungen" mit Crosscutting Concerns gleichgesetzt, was eindeutig falsch ist. Oder in anderen Publikationen wird schon in der Anforderungsphase von Aspekten gesprochen. Sofern geringe Abweichungen beachtet werden, können Aspekte nach ähnlichen Kriterien wie Komponenten modularisiert werden. Damit ordnen sich Aspekte und Komponenten unterhalb des Begriffes Modul ein. Bei der Umsetzung der AOP ist AspectJ der am weitesten fortgeschrittene und universellste aller Ansätze. In den früheren Entwicklungsphasen gibt es eine große Vielfalt von unterschiedlichen Vorgehensweisen. Hinsichtlich der Spezifikationssprache ist mit der Unified Modelling Language (UML) eine Möglichkeit gegeben.

http://www.aspectj.org

http://www.aosd.net

http://www.eclipse.org/aspectj

http://www.parc.com

Informationen zum Artikel
Deutsch: Aspektorientierte Programmierung
Englisch: aspect oriented programming - AOP
Veröffentlicht: 27.10.2013
Wörter: 984
Tags: #Programmiersprachen
Links: Architektur, AspectJ, Aspekt, C++, Code