Aspect J

[Hans]

Hi !

Kann mir jemand mal erklären, was DAS TOLLE an Aspect J sein soll ? Vielleicht bin ich ja auf dem Holzweg, aber das ganze Aspect-Gelumpe mit Pointcut, Before und After kann ich doch auch mit ganz normalen Logging-Anweisungen (z.B. System.out.println("Aufruf von Methode xy mit Parameter a=5, b=7") zu Beginn der Methode xy) bzw. dem üblichen try-catch-Kontrukten machen, oder ?

Oder hat jemand einen anderen "Aspekt" ? ;-)

Gruß

Hans

[lina-]

moin Hans :)

Vielleicht bin ich ja auf dem Holzweg, aber das ganze Aspect-Gelumpe mit Pointcut, Before und After kann ich doch auch mit ganz normalen Logging-Anweisungen ... bzw. dem üblichen try-catch-Kontrukten machen, oder ?

_Können_ kann man das - aber genau aus diesem Grund wurde ja AOP (Aspektorientierte Programmierung) "erfunden".

Nehmen wir mal ein praktisches Beispiel. Du möchtest loggen, welche Mehtoden ausgeführt werden aus deiner Klasse.
Mit normalen Logging-Anweisungen würdest du nun jeder Methode einen Logger geben und eine Anweisung z.B. "Führe Methode 'foobar()' aus".
Was machst du nun aber, wenn du lieber die Anweisung "foobar() wurde gestartet" haben möchtest. Genau.. du musst diesen String in _jeder_ Methode ändern. Wäre es da nicht schöner, du könntest das an einer Stelle ändern und es greift für alle?

Freilich ist dies hier ein Trivialbeispiel - aber vielleicht macht das den Sinn von AOP etwas klarer. Es geht hier um Effizienz, Nachvollziehbarkeit und Wartbarkeit.
Was anzustreben ist, ist die vernünftige Kapselung von Quellcode der Systemnahe Belange behandelt (System-Level-Cores). Hierzu gehört neben Logging auch Performance und Security.

liebe Grüße aus Berlin
lina-

[Daniel Thoma]

Hallo Hans,

Kann mir jemand mal erklären, was DAS TOLLE an Aspect J sein soll ? Vielleicht bin ich ja auf dem Holzweg, aber das ganze Aspect-Gelumpe mit Pointcut, Before und After kann ich doch auch mit ganz normalen Logging-Anweisungen (z.B. System.out.println("Aufruf von Methode xy mit Parameter a=5, b=7") zu Beginn der Methode xy) bzw. dem üblichen try-catch-Kontrukten machen, oder ?

Ja das kann man. Die Idee von AOP ist aber, solche verschiedenen Aspekte einer Klasse getrennt implementieren zu können und so übersichtlicheren Code zu bekommen.

Das logging-Beispiel ist so das Standardbeispiel für AOP. Das funktioniert auch sehr schön, weil logging den eigentlichen Programmablauf ja nicht verändert.
Ein anderes Beispiel ist z.B. eine Schicht für Zugriffsberechtigungen z.B. für die Verwaltung von Bankkonten (das Standardbeispiel für objektorientierten Entwurf ;-) Mit AOP könnte man erst mal die eigentlichen Operationen wie Überweisen implementieren und dann einen Aspekt dazu packen, der vor den einzelnen Operationen die entsprechenden Überprüfungen durchführt.

Ich habe das bisher noch nicht praktisch ausprobiert aber bislang bin ich aus mehreren Gründen nicht wirklich überzeugt:

• AOP zerstört die Modularität. So kann ein Aspekt das verhalten einer Klasse von außen verändern ohne dass die Klasse dies vorsieht. Vererbung kann das zwar auch, aber nicht ohne dass das entstandene Objekt seinen Typ ändert und auch nur viel eingeschränkter.
• Es gibt verschiedene Entwurfsmuster um ähnliche Funktionalität zu ereichen. Man könnte z.B. eine ereignisbasierte Schnittstelle zur Klasse hinzufügen, die Logging oder den Eingriff in den Programmablauf z.B. für oben beschriebene Zugriffskontrolle erlaubt. Man könnte auch das Decorator-Muster verwenden und das verhalten damit in 3 getrennten Schichten realisieren.
• Das Hinzufügen von weiteren, nicht beim Entwurf der eigentlichen Klasse angedachten Aspekten ist ein Märchen. Die Klasse muss die Operationen schon so untergliedert haben, dass man da mit AOP vernünftig eingreifen kann.
  Bei Logging ist das noch kein Problem, bei dem Zugriffsrechte-Beispiel muss man aber z.B. mindestens einen Parameter für den Benutzernamen vorsehen, obwohl den die Klasse selbst nicht braucht. Aber ein Aspekt kann ja nicht die Signatur einer Methode ändern.
• Soweit ich das überblicke gibt es keine (sinnvolle) Regelung für die Reihenfolge mehrer Aspekte, die an den selben Stellen in den Ablauf eingreifen. Mir scheint, dass da Programmverhalten verteilt wird, das womöglich zusammenhängt und auch nicht unabhängig verändert werden kann.
• AOP ist kein Ersatz für oben erwähnte objektorientierte Lösungsanstäze. Diese sind im Gegensatz zu AOP auch zur Laufzeit rekonfigurierbar.

Grüße

Daniel