imported>SchlurcherBot: Bot: http → https

2026-02-21T09:34:08Z

Bot: http → https

Neue Seite

'''Aspektorientierte Programmierung''' ('''AOP''') ist ein [[Programmierparadigma]] für die [[objektorientierte Programmierung]], um generische Funktionalitäten über mehrere Klassen hinweg zu verwenden ([[Cross-Cutting Concern]]). Logische ''Aspekte'' eines [[Anwendungsprogramm]]s werden dabei von der eigentlichen Geschäftslogik getrennt. Typische Anwendungsbeispiele sind [[Transaktion (Informatik)|Transaktionsverwaltung]], [[Audit]]fähigkeit und [[Logging]]verhalten.

Das Konzept von AOP wurde von Gregor Kiczales und seinem Team am [[Xerox PARC]] entwickelt. Im Jahr 2001 wurde dort auch die erste AOP-Sprache [[AspectJ]] vorgestellt.

== Motivation ==
Software hat grundsätzlich bestimmte Aufgaben/Anforderungen zu erfüllen. Diese Anforderungen kann man grob in zwei Bereiche gliedern:
# Die sogenannten ''Core-Level-Concerns'' (betreffen den logischen „Kern“ der Anwendung) oder funktionale Anforderungen. Dies sind Anforderungen an die Software, die man meist gut in einzelnen Funktionen kapseln kann. Ein Beispiel wäre die Berechnung eines Wertes.
# Die ''System-Level-Concerns'' (betreffen das gesamte System) oder technische Randbedingungen. Diese Anforderungen können nicht einfach gekapselt werden, da sie an vielen Stellen implementiert werden müssen. Ein Paradebeispiel dafür ist das ''Logging'', die Protokollierung des Programmablaufs in Logdateien. Der Aufruf des Loggers ist für die eigentliche Funktionalität nicht notwendig, muss aber trotzdem in den Quelltext integriert werden. Ein weiteres Beispiel wäre die Transaktionierung von Zugriffen auf eine Ressource wie z. B. eine Datenbank.

Diese beiden Teile sind miteinander verwoben. Die Core-Level-Concerns kann man als Komponenten bezeichnen, und die System-Level-Concerns sind die Aspekte. Core-Level-Concerns werden üblicherweise als [[Modul (Software)|Module]] oder [[Objekt (Programmierung)|Objekte]] implementiert. Für die Aspekte gab es vor der aspektorientierten Programmierung keine elegante Lösung.

Das Problem der miteinander verwobenen Anforderungen wird auch als [[Cross-Cutting Concern]]s bezeichnet, denn sie „schneiden“ quer durch alle logischen Schichten des Systems. AOP ist das Werkzeug, um die logisch unabhängigen Belange auch physisch voneinander zu trennen. Dabei wird angestrebt, Code zu erzeugen, der besser [[Wartung|wartbar]] und [[Wiederverwendung|wiederverwendbar]] ist.

In diesem Zusammenhang sind ''System-Level-Concerns'' aber nicht gleichzusetzen mit rein technischen Belangen. Auch fachliche Belange wie z. B. die Umsetzung eines eigenen, fachlichen Berechtigungssystems für Benutzer können durchaus Aspektcharakter haben.

== Hintergrund ==
In der Geschichte der Entwicklung der [[Programmiersprache]]n wurden immer wieder neue Konzepte der Programmierung und diese implementierende Hochsprachen entwickelt, angefangen bei der Programmierung in [[Assemblersprache|Assembler]], welche das direkte Programmieren in [[Binärcode]] ablöste, über prozedurales und funktionales Programmieren, bis hin zu den heute aktuellen objektorientierten Sprachen. Der Zweck ist, den Entwicklern die Arbeit zu erleichtern und somit eine bessere Effizienz in der Entwicklung der Software zu erzielen. Eines der zugrundeliegenden Prinzipien, das bei allen neuen Programmierkonzepten angewendet wurde, war das der Kapselung von Funktionalität.

* [[Assemblersprache]]n kapseln Binärbefehle für [[Arbeitsspeicher]]- und [[Register (Computer)|Register]]zugriffe in kurzen, generalisierten [[Zeichenkette]]n und befreien den Softwareentwickler damit von der Notwendigkeit, sich mit der Binärcodierung zu beschäftigen.
* [[Prozedurale Programmiersprache|Prozedurale Sprachen]] erlauben die Kapselung einfacher Funktionen, wie das Sortieren einer Namensliste, innerhalb einer [[Prozedur (Programmierung)|Prozedur]]. Damit entfällt die Notwendigkeit von Zeilennummern und daran gebundenen Sprungbefehlen sowie das mehrfache Entwickeln derselben [[Funktion (Programmierung)|Funktion]] an verschiedenen Stellen des Programmcodes.
* [[Objektorientierte Programmiersprache]]n erlauben die Kapselung konzeptionell zusammengehöriger Funktionen und Variablen in unabhängigen Modulen (Klassen) mit klar definierten Schnittstellen, wodurch die [[Wiederverwendbarkeit]] der einzelnen Module erhöht wird und der Softwareentwickler davon befreit ist, sich mit der internen Implementierung der von ihm verwendeten Klassen auseinanderzusetzen.

Eine erweiterte Funktionalität zu ermöglichen, ist nicht Ziel dieser Entwicklung, weil jede Hochsprache nach der Kompilierung auf Maschinencode abgebildet wird.

Insbesondere erleichtert die Kapselung von Funktionalität die Entwicklung von Software, indem Wartbarkeit und Wiederverwendbarkeit existierenden Programmcodes erhöht werden. Da [[Software]] im Laufe der Zeit immer komplexer und umfangreicher wird, und damit die Entwicklung zeitaufwendiger und teurer, gewannen diese beiden Ziele immer mehr an Bedeutung und sind heute zentrale Elemente bei der Entwicklung neuer Programmierkonzepte und -sprachen.

Bei AOP (aspect-oriented programming bzw. aspektorientierte Programmierung) handelt es sich um ein Programmierkonzept, welches das Problem der sogenannten [[Cross-Cutting Concern]]s behandelt.

Die kostengünstige und termingerechte Entwicklung und Wartung qualitativ hochwertiger [[Software]] ist das Primärziel des [[Software Engineering]]. Um dieses Ziel zu erreichen, ist eine möglichst [[Modul (Software)|modularisierte Software]] mit einer möglichst geringen [[Komplexität]] der Module notwendig.

In einem konventionellen System, wobei hier auch die objektorientierten Ansätze hinzugehören, können Kernfunktionalitäten, englisch ''core concerns'', für sich allein betrachtet nach den Regeln der Kunst sauber in Module getrennt werden. Es gibt jedoch ''concerns'' (Anliegen, Belange, Anforderungen) wie Fehlerbehandlung, [[Rechenleistung|Performance]] und Sicherheit in jedem System, die die Kernfunktionalitäten quer schneiden (eng. ''cross cut'') und sich deshalb nicht eindeutig einem Software-Modul zuordnen lassen. Dies führt dazu, dass Fragmente solcher ''cross cutting concerns'' (quer schneidende Kernfunktionalitäten ''(übergreifende Anforderungen)'' – fehlende [[Kohäsion (Informatik)|Kohäsion]]) nicht zugeordnet und ungekapselt im ganzen Code verstreut sind. Diese quer schneidenden Kernfunktionalitäten verhindern in konventionellen Softwaresystemen eine saubere Modularisierung und beeinträchtigen Pflege, Verständlichkeit, Wiederverwendbarkeit und (Rück-)Verfolgbarkeit. Verantwortlich hierfür ist bei konventionellen [[Programmiersprache]]n die [[Systemdekomposition]], die nur eine Dimension zulässt – die Liste von Funktionen. Dieses Phänomen nennt man auch ''dominante Dekomposition''. Mit anderen Worten: ein natürlicherweise mehrdimensionales Problem muss eindimensional gelöst werden.

== Ableitung aus früheren Paradigmen ==
In der prozeduralen Programmierung ist die Ausführung von Code vergleichsweise linear. Durch Verfolgung der Symbole ist jeder einzelne Programmschritt auch bei der Betrachtung eines Teilsystems direkt nachvollziehbar. Beispiel in ''C'':

<syntaxhighlight lang="c">
void function (void * c)
{
Component_repaint(c);
}
</syntaxhighlight>

Die Funktion <code>Component_repaint()</code> ist eindeutig. Unabhängig davon, ob der Zeiger <code>c</code> den dynamischen Typ <code>Component</code> oder einen abgeleiteten Typ hat, wird immer dieselbe Funktion <code>Component_repaint(Component*)</code> aufgerufen ([[statische Typisierung]]).

In der objektorientierten Programmierung wird die Nachvollziehbarkeit durch die [[Polymorphie (Programmierung)|Polymorphie]] reduziert.
Beispiel in ''Java'':

<syntaxhighlight lang="java">
void function (Component c)
{
c.repaint();
}
</syntaxhighlight>

Es ist anhand des Quelltextes nicht nachvollziehbar, welche <code>repaint()</code>-Methode ausgeführt wird, das hängt vom Laufzeit-Typ des Objekts ab, das von <code>c</code> referenziert wird. Ein von <code>Component</code> abgeleiteter Typ könnte seine eigene <code>repaint()</code>-Methode definieren, indem er die von <code>Component</code> [[Vererbung (Programmierung)|geerbte]] Methode <code>repaint()</code> überschreibt.

In der aspektorientierten Programmierung wird die Nachvollziehbarkeit durch die Verwendung von ''[[#Begriffe|Pointcuts]]'' weiter reduziert. Ein ''Pointcut'' enthält für einen ''[[#Begriffe|Join-Point]]'' auszuführenden Code, ein ''Join-Point'' ist dabei ein genau definiertes Aufrufereignis. Hier können zu nahezu beliebigen Punkten in der Aufrufkette ''Advices'' aktiviert werden. Damit ist es im Extremfall sogar möglich, den Aufruf der Methoden <code>function()</code> oder <code>repaint()</code> an sich zu verhindern. So könnte man sich einen Aspekt vorstellen, der für den ''Join-Point'' „Aufruf der Methode <code>function()</code>“ einen ''Advice'' definiert, der explizit die weitere Abarbeitung dieses Funktionsaufrufs untersagt. Ebenso könnte man in einem ''Advice'' festlegen, dass anstatt der Methode <code>repaint()</code> eine andere Methode auf das Objekt angewandt werden soll. Die Information darüber, was als Nächstes geschehen soll, ist dabei am Ort des Geschehens selbst zunächst nicht abzulesen.

=== Vergleiche ===
Zum besseren Verständnis der Konzepte von ''Pointcuts'', ''Join-Points'' und ''Advices'' dienen die Vergleiche mit den nachstehenden älteren Paradigmen.

==== Structured Query Language (''SQL'') ====
Man stelle sich ein ''[[SQL#Spaltenauswahl|SELECT]]''-Statement vor, das alle Methoden in allen Klassen eines Systems selektieren kann. In diesem Zusammenhang entspricht dann
* ein ''Pointcut'' der ''[[SQL#Filter|WHERE]]''-Klausel, welche die Menge der selektierten Methoden einschränkt
* ein ''Join-Point'' einem konkreten Suchergebnis im Sinne eines [[Datensatz]]es aus einer [[Datenbank]] – nur, dass hier keine Datensätze aus einer Datenbank selektiert werden, sondern Methoden in einem System
* ein ''Advice'' der Methode in einem Aspekt, die vor, nach oder anstatt der ausgewählten Methode ausgeführt werden soll.

==== Andere Programmierparadigmen ====
Während in der prozeduralen Programmierung die Nachvollziehbarkeit durch ein Quelltextfragment und in der objektorientierten Programmierung unter zusätzlicher Kenntnis über die Laufzeittypen vergleichsweise direkt gegeben ist, erfordert die Nachvollziehbarkeit in der aspektorientierten Programmierung die Kenntnis sämtlicher Aspekte, die Point-Cuts für die Join-Points des Code-Fragment definieren.

''Orthogonal'' bedeutet hier, dass Eigenschaften von Methoden „senkrecht“ zur normalen Programmierrichtung definiert werden. Die tatsächliche Code-Ausführung wird nicht nur durch die Aufruf- und Typenhierarchie, sondern zusätzlich „senkrecht“ (orthogonal) dazu von den Aspekten definiert.

=== Analogie ===
Anschaulich kann man sich das Prinzip wie folgt vorstellen: ein Programm, gleichgültig ob prozedural oder objektorientiert, folgt einem [[Programmablaufplan]], d. h. der Programmfluss ist an jeder Stelle durch lineare Folgen von Anweisungen ([[Blockstruktur|Codeblöcke]]) und [[Sprunganweisung|Sprünge]] zwischen diesen (z. B. Methodenaufrufe) festgelegt. Ein Aspekt wäre hier so viel wie eine Schablone, die über diesen Originalplan gelegt wird und verschiedene Änderungen oder Ergänzungen am Ablaufschema vornimmt. Änderungen an der Schablone lassen den Originalplan unangetastet, die Schablone lässt sich jederzeit austauschen, mit anderen kombinieren oder wieder entfernen.

=== Technische Betrachtung ===
In einer objektorientierten Laufzeitumgebung könnte aspektorientierte Programmierung durch veränderbare [[Vektor (Begriffsklärung)|Sprungvektoren]] ermöglicht werden. Man kann sie als eine Art im Programmierparadigma vorgesehenes „Patchen“ von Funktionen ansehen.

Ein Objekt C wird in die Lage versetzt, Interaktionen zwischen zwei Objekten A und B zu überwachen, ohne dass dafür Veränderungen oder Erweiterungen am Quelltext, der A und B implementiert, notwendig sind. Natürlich ist tatsächlich doch eine Veränderung von A oder B oder beiden notwendig. ''AspectJ'' erzeugt diese Änderungen automatisch, der Vorgang dafür heißt ''[[Weaving (AOP)|Weaving]]'', da besagte Änderungen vor dem Kompilieren in den Originalcode „eingewebt“ werden.

== Einsatzgebiete ==
Die aspektorientierte Programmierung ist in der Lage, die bisher in der objektorientierten Programmierung eingesetzte [[Ereignis (Programmierung)|ereignisgesteuerte Programmierung]] (Event-Handling) ganz zu ersetzen.
Die ereignisgesteuerte Programmierung dient dazu, ein Objekt X über Veränderungen an einem Objekt Y zu benachrichtigen. Das Objekt Y braucht das Objekt X dabei aber nicht zu kennen.
Die bisherige Lösung wird hier am Beispiel eines Fensters in Java (java.awt.Frame) erklärt. Zu Ereignissen, die speziell für Fenster eintreten und über die ein anderer Programmteil benachrichtigt werden soll, zählt unter anderem das Schließen, das Aktivieren und das Deaktivieren. Eine Schnittstelle java.awt.event.WindowListener definiert dafür unterschiedliche Methoden und muss von den Objekten, die über Veränderungen am Fenster benachrichtigt werden möchten, implementiert werden. Objekte, die benachrichtigt werden möchten, müssen sich bei dem jeweiligen anderen Objekt (hier: dem Fenster) registrieren.

Die aspektorientierte Programmierung kann die Definition solcher Schnittstellen überflüssig machen. Ein Aspekt X definiert für das zu überwachende Objekt Y die genau zu überwachenden Code-Ereignisse, genannt Point-Cut, zusammengesetzt aus Join-Points (Gesamte Methode, Methoden-Aufruf, Methoden-Rückkehr unterscheidbar in Methoden-Rückkehr mit Rückgabewert und Methoden-Rückkehr mit Exception), und definiert für die verschiedenen Point-Cuts den Advice, das ist der auszuführende Code. Die Ausführung von Code in X durch Veränderungen an einem Objekt Y kann also ohne zusätzliches Interface, Methoden und Registrierungsmechanismus erfolgen.

Aspektorientierte Programmierung kann bei der Entwicklung von Frameworks (Libraries) eingesetzt werden, um z. B. Eigenschaften wie Persistenz oder Synchronisierbarkeit zu implementieren. Der Transfermechanismus bleibt dann vor dem Benutzer der Bibliothek verborgen. Das Verbergen des Transfermechanismus macht den Code in diesem Fall übersichtlicher, da die Methoden nicht mit Framework-Code überfrachtet werden.

Ein weiteres Einsatzgebiet ist das Software-Testen, wo insbesondere das Einführen neuer Attribute in Klassen ohne die Veränderung ihrer Quelltexte (Inter-type Declarations) neue interessante Möglichkeiten für die Entwicklung von White-Box-Tests darstellt, z. B. um ein Tracing privater Attribute durchzuführen.

== Joinpoint vs. Joinpoint shadow ==
Es muss zwischen Joinpoints und den sogenannten Joinpoint shadows unterschieden werden. Ein Joinpoint shadow ist das statische Vorkommen eines potentiellen Joinpoints. Ob dieser shadow (etwa ein im Quellcode stehender Methodenaufruf) tatsächlich zu einem Joinpoint wird, entscheidet sich erst zur Laufzeit in Abhängigkeit vom korrespondierenden Pointcut (resp. Pointcut-Designator).

Ein Pointcut definiert eine Menge von Joinpoint shadows, die er aus dem zugrunde liegenden Programm herausschneidet (cut). Wird während des Programmablaufs ein Joinpoint shadow betreten und ist sein definierender Pointcut erfüllbar, wird der „Joinpoint shadow“ zum „Joinpoint“.

== Beispiel ==
Folgendes Beispiel erläutert den Grundgedanken der aspektorientierten Programmierung. Die verwendete Programmiersprache ist [[AspectJ]], die [[Java (Programmiersprache)|Java]] um die Aspektorientierung erweitert.

=== Einführendes Beispiel ===
Als einführendes Beispiel soll eine Standardaufgabe bei der Softwareentwicklung dienen: [[Tracing]] von Informationen in eine Datei. Das Vorgehen ''ohne'' aspektorientierte Programmierung besteht darin, einen [[Logging|Logger]] zu erzeugen und dort eine entsprechende Methode aufzurufen, die die eigentliche Information in die Logdatei speichert:
<syntaxhighlight lang="java">
public void eineMethode() {
logger.trace("Betrete \"eineMethode\"");

// Abarbeitung der Methode
m = a + 2;

logger.trace("Verlasse \"eineMethode\"");
}
</syntaxhighlight>
Zu Beginn der Methode wird an den Logger gemeldet, dass die Methode betreten wird. Danach folgt die eigentliche Logik der Methode. Zum Schluss wird das Verlassen der Methode protokolliert.

In einer typischen Anwendung sind derartige Methodenaufrufe an den Logger in vielen Methoden und Klassen vorhanden – sie sind über die gesamte Anwendung verstreut und keinesfalls modular. Der Logger
* muss jedem Objekt bekannt gemacht werden und
* kann nicht ohne weiteres an einer zentralen Stelle ausgetauscht werden – jedenfalls nicht, ohne diesen im System public static zu deklarieren, was einer globalen Variablen und somit zweifelhaftem Design gleichkommt.

Somit wird auch klar, was mit ''semantisch und physisch unabhängige Programmstrecken'' gemeint ist. In obiger Methode sind zwei eigentlich unabhängige Aufgaben miteinander vermengt. Dies ist zum einen das Protokollieren und zum anderen die eigentliche Logik der Methode, die darin besteht, das Ergebnis einer Addition in der Membervariablen ''m'' zu speichern.

Die aspektorientierte Programmierung erlaubt es nun, auch Aufgaben wie das Tracing zu modularisieren. Angenommen, das Betreten und Verlassen ''einer jeden'' Methode der Klasse soll auf die oben gezeigte Weise protokolliert werden. Gegenüber der konventionellen Programmierung lässt sich eine solche Anweisung in der AOP direkt als ''[[Aspekt (Informatik)|Aspekt]]'' formulieren:
<syntaxhighlight lang="java">
public aspect Tracing {
pointcut traceCall():
call(* AOPDemo.*(..));

before(): traceCall() {
System.out.println("Betrete \"" + thisJoinPoint + "\"");
}

after(): traceCall() {
System.out.println("Verlasse \"" + thisJoinPoint + "\"");
}

}
</syntaxhighlight>

Im Aspekt wird bestimmt, dass alle Methoden der Klasse AOPDemo unabhängig von ihrer [[Signatur (Programmierung)|Signatur]] einbezogen werden sollen. Die Aufgaben werden auf diese Weise separiert und die ursprüngliche Methode kann verkürzt geschrieben werden:
<syntaxhighlight lang="java">
public void eineMethode() {
// Abarbeitung der Methode
m = a + 2;
}
</syntaxhighlight>

=== Weiterführendes Beispiel ===
Außerdem ermöglicht die aspektorientierte Programmierung eine Umleitung des ursprünglichen Programmablaufs. Sicherheitsaspekte können zum Beispiel den ursprünglichen Programmablauf austauschen, um unberechtigte Zugriffe auf geschützte Programmteile zu verhindern. Caching-Aspekte erhöhen die Ausführungsgeschwindigkeit von Programmen und werden eingesetzt, um den Aufruf aufwendiger Programmteile wie Datenbank- oder Dateisystemzugriffe zu reduzieren. Das folgende Beispiel demonstriert die Umleitung von Methodenaufrufen bzw. den Austausch von Programmteilen als Interception Around Advice:<ref>[http://static.springframework.org/spring/docs/2.5.x/reference/aop-api.html#aop-api-advice-around Interception Around Advice]</ref>
<syntaxhighlight lang="java">
public aspect Caching {

pointcut cacheCall():
call(* AOPDemo.*(..));

private Map cache = new Map();

around(): cacheCall(Joinpoint joinPointContext) {

// Prüfen, ob Rückgabewert für aktuelle Aufruf-Argumente schon im Cache abgelegt wurde
Object args = joinPointContext.getArguments();
boolean isCallCached = cache.containsKey(args);

if (isCallCached) {
// Umleitung und Austausch des ursprünglichen Methodenaufrufs, gesicherten Rückgabewert aus Cache verwenden
Object cachedReturnValue = cache.get(args);
return cachedReturnValue;
}
else {
// Weiterleitung an ursprüngliche Methode und neuen Rückgabewert im Cache sichern
Object newReturnValue = joinPointContext.proceed();
cache.put(args, newReturnValue);
return newReturnValue;
}
}
}
</syntaxhighlight>

=== Begriffe ===
Das Beispiel beinhaltet bereits die wichtigsten Konzepte, wenn auch nicht alle. In diesem Abschnitt werden die fehlenden hinzugefügt und den in der AOP verwendeten Begriffen zugeordnet.

Dazu wird das Beispiel um folgende Codesequenz erweitert und der bisherige Ablauf grafisch dargestellt:

<syntaxhighlight lang="java">
public void quellMethode() {
eineMethode();
}
</syntaxhighlight>

[[Datei:Aspektorientierte Programmierung.svg|Schematische Darstellung der Verwendung eines Aspekts]]

Der Aspekt kommt zum Tragen, noch bevor <code>eineMethode()</code> betreten wird. Der Grund dafür ist der '''Join Point''' direkt davor. Diese Join Points sind implizit gegeben. Das heißt, sie sind vor jeder Methode vorhanden. Das Muster, das aus allen vorhandenen Join Points diejenigen aussucht, die für einen Aspekt interessant sind, nennt sich '''Pointcut'''. Tatsächlich handelt es sich bei den Pointcuts um Muster, die auch [[Wildcard (Informatik)|Wildcards]] erlauben. Um festzulegen, wann welcher Code innerhalb des Aspekts auszuführen ist, kommen '''Advices''' zum Tragen. Im einführenden Beispiel sind dies ''before'' und ''after'', im weiterführenden Beispiel ''around''. Diese Advices sind, neben weiteren, implizit gegeben.

Die Programmierung mit Aspekten erlaubt es zudem, in und mit Aspekten das Verhalten von Klassen zu verändern. Es können durch Aspekte Felder und Methoden zu Klassen hinzugefügt werden. Auch hier ist es durch die Angabe von Wildcards gleichzeitig bei mehreren Klassen möglich. In einer Sprache wie [[Java (Programmiersprache)|Java]] verletzen diese '''Inter-Type Declarations''' die Regel, dass sämtliche Felder und Methoden einer Klasse in einer Datei, bzw. der [[Vererbung (Programmierung)|Vererbungshierarchie]] der Klasse zu finden sind, da Aspekte dieser nicht angehören.

== Typische Aufgaben ==
AOP ist besonders zur Programmierung von sogenannten [[Cross-Cutting Concern]]s geeignet. Beispiele dafür sind [[Logging|Protokollierung]], [[Ausnahmebehandlung|Fehlerbehandlung]], [[Persistenz (Informatik)|Persistenz]], [[Datenvalidierung]] und [[Informationssicherheit|IT-Sicherheit]].

[[Profiler (Programmierung)|Profiling]] APIs, wie bspw. in [[Java (Programmiersprache)|Java]] enthalten, arbeiten auf ähnliche Weise wie AOP. Sie dienen dazu, unperformante Codestellen zu ermitteln. Dazu werden durch einen sog. Profiler Zeitmessungen für die Abarbeitung sämtlicher Methoden angestellt. Der eigentliche Profiler kann sich von der [[Virtuelle Maschine|Virtual Machine]] mitteilen lassen, wann eine Methode betreten und verlassen wird. Mit aspektorientierter Programmierung lässt sich daher auch ein Profiler realisieren.

== Ähnliche Lösungsansätze ==
Aspekte haben ihren Ursprung in der [[Objektorientierte Programmierung|objektorientierten Programmierung]] und sind zumindest in ihrer Intention vergleichbar mit Metaobjektprotokollen, wie man sie beispielsweise im [[Common Lisp Object System]] vorfindet. Ferner sind Aspekte mit Konzepten wie der [[Subjektorientierte Programmierung|subjektorientierten Programmierung]], den [[Mixin]]s, den [[Classbox]]es oder dem Konzept der [[Delegation (Softwareentwicklung)|Delegation]] verwandt, wie es in der Programmiersprache [[Self (Programmiersprache)|Self]] vorzufinden ist. Einen ähnlich gelagerten oder gar gleichwertigen Lösungsansatz stellen die sogenannten [[Trait (Programmierung)|Traits]] dar.

== Anmerkungen ==
Vorteil der Aspektorientierung ist die logische und physische Trennung der Semantik (der Komponente) von dem technischen Detail (Aspekt). Als Nachteil der aspektorientierten Programmierung sei hier insbesondere der ''Overhead'' erwähnt, der nach dem ''Weaving'' im generierten Programm entsteht. Dies führt im Allgemeinen zu [[Rechenleistung|Performance]]-Einbußen. Des Weiteren reduziert aspektorientierte Programmierung die Nachvollziehbarkeit von Programmverhalten, da die Stellen, an denen ein Aspekt zuständig ist, im betroffenen Code nicht direkt erkennbar sind. [[Debugging]] wird so stark erschwert, allerdings kann dieser Nachteil durch Unterstützung einer [[Integrierte Entwicklungsumgebung|IDE]] neutralisiert oder zumindest reduziert werden, indem das Debugging ebenso mehrdimensional vor sich geht wie das Entwickeln des Codes.

Ein weiterer Nachteil ist, dass beim Einsatz dieser Technik unerwünschte und schwer nachvollziehbare Wechselwirkungen zwischen einzelnen Aspekten auftreten können.

Aspekte und Komponenten können in verschiedenen Programmiersprachen definiert sein.

== Siehe auch ==
* [[Reflexion (Programmierung)]]

== Literatur ==
* Lars Wunderlich: ''AOP: Aspektorientierte Programmierung in der Praxis.'' Entwickler.press, Frankfurt am Main 2005, ISBN 3-935042-74-4.
* Oliver Böhm: ''Aspektorientierte Programmierung mit AspectJ 5: Einsteigen in AspectJ und AOP.'' Dpunkt Verlag, Heidelberg 2006, ISBN 3-89864-330-1.
* Renaud Pawlak, Lionel Seinturier, Jean-Philippe Retaille: ''Foundations of AOP for J2EE Development (Foundation).'' Apress, Berkeley CA 2005, ISBN 1-59059-507-6.
* Ralf Westphal: ''Aspektorientierte Programmierung mit .NET.'' In: ''dotnetpro'' Ulm 22.2007,10. {{ISSN|1610-1553}}

== Weblinks ==
* [https://common-lisp.net/project/closer/aspectl.html AspectL.] Aspektorientierte Programmierung für Lisp
* [https://eclipse.org/aspectj/ AspectJ.] Aspektorientierte Programmierung für Java
* [http://www.rapier-loom.net/ LOOM.NET] – Aspektorientierte Programmierung für .NET
* [https://www.aspectc.org/ AspectC++.] Aspektorientierte Programmierung für C++
* [https://wwwiti.cs.uni-magdeburg.de/iti_db/forschung/fop/featurec/ FeatureC++.] Kombination von merkmalsorientierter Programmierung und aspektorientierter Programmierung für C++
* [https://www.theserverside.de/funf-wege-der-fehlersuche-in-java/ Fehlersuche mit aspektorientierter Programmierung in Java] (deutsch)
* [http://flow3.typo3.org/ FLOW3 – PHP Framework mit AOP]
* [https://aop.io/ PHP-AOP (AOP.io). aspektorientierter Programmierung in PHP]
* [https://go.aopphp.com/ Go! Aspektorientierte Programmierung für PHP]
* [http://code.google.com/p/loom-as3/ loom-as3 – ActionScript3 AOP Bytecode Weaver]
* [https://github.com/forensix/MGAOP/ Aspektorientierte Programmierung für Objective-C]

== Einzelnachweise ==
<references />

[[Kategorie:Programmierparadigma]]

Aspektorientierte Programmierung - Versionsgeschichte

imported>SchlurcherBot: Bot: http → https