AOP und folgende Idee

[Andreas29]

Hi,

ich habe jetzt einiges über die AOP gelesen und frage mich, ob man darüber nicht ein schönes logging entwickeln kann, bei dem ich ihm sage:
Webe mir in den Code log-Ausgaben beim Methodenaufruf und beim Verlassen einer Methode ein. Sprich, ich würde hinterher in meinem Log gerne sehen, welche Methoden in welcher Reihenfolge aufgerufen wurden. Lässt sich so was mit AOP machen? Ich möchte hier keine fertige Lösung (die möchte ich mir selbst erarbeiten), sondern nur eine Aussage, ob sich das realisieren lässt oder ob ich doch von Hand die Log-Ausgabe erzeugen muss. Von Hand ist mir zu fehleranfällig...

Grüße,
Andreas

 

[ARadauer]

klar logging ist doch das standard beispiel für aspektorientierte programmierung, oder?

 

[SnooP]

Ja.. und dann auch fast noch das Einzige

 

[ARadauer]

@Snoop: stimmt.

ich halte persönlich sehr wenig von aspektorientierter programmierung. ich denke das kann die kompexität des debuggens enorm erhöhen.

 

[Andreas29]

Hi,

sicherlich erhöht es die komplexität des debuggens. Und genau das ist der Grund, warum ich es für das Logging und für nichts anderes einsetzen möchte. Ich möchte halt ohne viel Aufwand in mir einen Trace erstellen. So ungefähr:
methode 1 aufgerufen
methode 2 aufgerufen
methode 3 aufgerufen
methode 3 verlassen
methode 2 verlassen
methode 1 verlassen

Und das sind für mich Dinge, die man sehr selten debuggen wird

Grüße,
Andreas

 

[kaesebrot]

Hi,

ich teile eure Meinung über AOP nicht. Es lassen sich einige Designprobleme viel eleganter und besser lösen, als es mit reiner Objektorientierung möglich ist. Natürlich kann man mit AOP auch viel Unfug machen, aber das geht mit den Konzepten der Objektorientierung auch.


viele Grüße,
Käse

 

[SnooP]

okay... welche designprobleme denn? Um es mal zu präzisieren - ich habe bislang noch keinen wirklich tollen cross-cutting-concern erlebt, bei dem es so herauszutrennen war, dass man aop also toll einsetzen konnte...

sicherlich kann man jetzt auch noch Transaktionen nennen und diese z.B. via Spring-AOP verwalten lassen - aber dann hört's bei mir spätestens auf. Außerdem hat man da immerhin noch die Möglichkeit entsprechende Methoden via Annotations zu markieren, was gegenüber dem magischen Namenskonventionensvorgehen bei den Joinpoints doch nen Vorteil beim debuggen ist.

Also los - überzeuge mich...

 

[kaesebrot]

Okay.. ich werde es versuchen.

Einige Ziele die man beim Software-Design verfolgt sind
* Wiederverwendbarkeit
* Verständlichkeit
* Keine Renundanzen

Nehmen wir an du hättest folgende Klassen:
Dokument, Seite, Absatz, Wort, Buchstabe, Bild, etc..
(die Struktur kann man sich ja denken)

Auf einer entsprechenden Objektstruktur möchte man jetzt ja sicherlich viele verschiedene Operationen ausführen, wie zum Beispiel: Rechtschreibprüfung, Einfärben, als PDF exportieren, etc..
Um das zu erreichen und um die Klassen nicht um jede Funktionalität erweitern zu müssen (was z.B. die Wiederverwendbarkeit verringern würde) könnte man das Visitor-Pattern anwenden. Die Funktionsweise ist ein wenig gewöhnungsbedürftig und wirft auch einige Probleme auf, wenn Operationen nicht auf alle Elemente angewendet werden (wie zum Beispiel Rechtschreibprüfung auf ein Bild-Element). Fakt ist, daß bei der Implementierung der Aspekt der jeweiligen Operationen auf viele Klassen verteilt ist. Wäre es nicht schöner das alles schön an einer Stelle finden zu können? Realisieren läßt sich das mit Inner-Type Declarations.

Mit AOP läßt sich zum Beispiel auch wunderbar ein bestehendes Datenmodell für ein JTree adaptieren. Der herkömmliche Weg wäre ja die Verwendung des Adapter-Patterns wobei die AOP-Lösung u.U. um einiges eleganter ist.

Ein weiteres Beispiel wäre ein Grafikprogramm. Die Zeichenfläche soll neu gezeichnet werden, wenn sich eines der Objekte ändert. Wo implementiert man das? Mit AOP kein Problem.


kann sein, daß ich einige grobe Patzer in den Beschreibungen gemacht habe. Bin relativ neu was AOP betrifft.



viele Grüße,
Käse

 

[kaesebrot]

Ich bin heute auf eine interessantes Paper gestoßen. Es geht um die Implementierung von Design-Patterns mittels AspectJ. Vieleicht kann dies besser überzeugen als meine umständlichen Erläuterungen. Das Paper findet sich hier:

:### http://hannemann.pbwiki.com/Design+Patterns

viele Grüße,
Käse

 

[SnooP]

Das sind auf jeden Fall schonmal interessante Gedanken... - aber letztlich ist das alles für mich nach wie vor kein Grund für AOP. Direkte Funktionalität, die mit meinen Objekten gekoppelt ist, wenn auch lose, sollte mir auch vor der Nase liegen. Mit OOP hab ich bereits diverse Möglichkeiten und Patterns um die von dir genannten Probleme zu lösen... wie z.B. Adapter zum Anpassen eines "inkompatiblen" Modells oder Klasse, Kapselung von Commands via visitor-Pattern oder Command-Patterns oder auch Strategy. Filter-Mechanismen etc... um noch losere Kopplungen zu erhalten, kann man auch Event-Mechanismen verwenden - wie z.B. property-Change zur Erkennung von Änderungen etc...

Ich sehe, dass man das mit AOP lösen könnte... man könnte Klassen zur Laufzeit auch via Code-Instrumentation verändern... aber ich sehe darin immer eine immense Fehlerquelle und eine Verwurschtelung des Designs und die Gefahr, dass man zuviel funktionalen code in diese Magic-Code-Blöcke hineinzieht... weil es halt so schön einfach geht... gerade das Anpassen eines Modells nur weil es mit AOP so einfach ist, führt spätestens beim Debuggen bzw. Refactoren oder Code sichten eines Neueinsteigers in ein Projekt doch zu sehr wirren Situationen... nach dem Motto - eigentlich sind diese Klassen noch völling inkompatibel, wo kommt der Code denn her? ...

Also ich find's nich gut ... und schon gar nicht elegant... aber ich möchte das auch nicht totreden und werde mir gerne weitere Argumente anhören ... wie gesagt bei echten Cross-Cutting-Concerns lass ich das auch gerne zu ... wie Transaction-Handling via Spring... nur sehe ich da persönlich kaum was von AOP und das ist auch gut so

 

[kaesebrot]

Das sind auf jeden Fall schonmal interessante Gedanken...

Sehe ich auch so

- aber letztlich ist das alles für mich nach wie vor kein Grund für AOP. Direkte Funktionalität, die mit meinen Objekten gekoppelt ist, wenn auch lose, sollte mir auch vor der Nase liegen.

tut es ja, man muß nur ein wenig an der Denkweise schrauben. Anfangs habe ich mich auch daran gestört, das die Funktionalität der Klasse nicht mehr bei der Klasse liegt. Fragt man jedoch nicht "Was kann die Klasse alles" sondern "Kann die Klasse das?" muß man nur in den zugehörigen Aspekt schauen und prüfen, ab die Klasse zugewiesen wurde.

Mit OOP hab ich bereits diverse Möglichkeiten und Patterns um die von dir genannten Probleme zu lösen... wie z.B. Adapter zum Anpassen eines "inkompatiblen" Modells oder Klasse, Kapselung von Commands via visitor-Pattern oder Command-Patterns oder auch Strategy. Filter-Mechanismen etc...

Die OOP-Lösungen der Patterns bringen einige Konsequenzen mit sich. Was machst du z.B. wenn du eine Klassenhierarchie adaptieren möchtest. Dann mußt du für jede konkrete Subklasse einen Adapter schreiben. Das adaptieren einer Composite-Struktur bringt auch Probleme mit sich. Weiterhin hast du Schwierigkeiten Observable-Funktionalität in eine Klassenhierarchie einzufügen, da du dann Mehrfachvererbung bräuchtest. Natürlich kann man auch diese Probleme lösen, jedoch ist dies mittels AOP besser möglich.

um noch losere Kopplungen zu erhalten, kann man auch Event-Mechanismen verwenden - wie z.B. property-Change zur Erkennung von Änderungen etc...

nur überschaubar ist das dann ab einer gewissen komplexität leider nicht mehr.

Ich sehe, dass man das mit AOP lösen könnte... man könnte Klassen zur Laufzeit auch via Code-Instrumentation verändern... aber ich sehe darin immer eine immense Fehlerquelle und eine Verwurschtelung des Designs und die Gefahr, dass man zuviel funktionalen code in diese Magic-Code-Blöcke hineinzieht... weil es halt so schön einfach geht... gerade das Anpassen eines Modells nur weil es mit AOP so einfach ist, führt spätestens beim Debuggen bzw. Refactoren oder Code sichten eines Neueinsteigers in ein Projekt doch zu sehr wirren Situationen... nach dem Motto - eigentlich sind diese Klassen noch völling inkompatibel, wo kommt der Code denn her? ...

Ich stimme dir zu. Man muß bei der Anwendung sehr diszipliniert sein und wohl überlegen wie man ein bestimmtes Problem lösen möchte. Aber das muß man auch ohne OOP. AOP bietet einiges an neuer Funktionalität die man natürlich auch kennen muß um sich in einem AOP Projekt zurecht zu finden. Aber ähnlich steht es mit OOP aus der Sicht eines Anhängers der funktionalen Programmierung.

Also ich find's nich gut ... und schon gar nicht elegant... aber ich möchte das auch nicht totreden und werde mir gerne weitere Argumente anhören ... wie gesagt bei echten Cross-Cutting-Concerns lass ich das auch gerne zu ... wie Transaction-Handling via Spring... nur sehe ich da persönlich kaum was von AOP und das ist auch gut so

Ich bin was AOP betrifft etwas aufgeschlossener und werde es auch in meinen Zukünftigen Projekten einsetzen.


Hast du das Paper mal überflogen? Was ich ziemlich reizvoll finde ist, daß man bei vielen Patterns die Implementierung nur einmal vornehmen muß und die Rollen dann je nach bedarf vergeben kann. Ich finde das sehr intuitiv: Du kennst Pattern X, siehst (bei Bedarf) die Implementierung im entsprechenden (abstrakten) Aspekt und kannst dir dann im konkreten Aspekt anschauen, welche Klasse, welche Rolle übernimmt.


viele Grüße,
Käse

 

[byte]

AOP ist ne gute Sache, wenn man weiss was man tut. Aber genau da liegt das Problem. Oft weiss man das nicht. Das liegt nicht daran, dass man blöd ist, sondern dass man Code reviewed, den man nicht selbst geschrieben hat. Und dann fangen die Probleme schon an. Ich kann nun nicht mehr einfach den Debugger nehmen und das Problem so weit wie nötig eingrenzen. Ich muss dann noch zusätzliches Knowhow über etwaige Aspekte haben und wo diese konfiguriert sind.

Daher kann ich SnooP nur zustimmen. Für gewisse Cross-Cutting-Concerns, die dann auch einheitlich im gesamten Projekt umgesetzt werden, ist das sicherlich ne gute Sache. Darüber hinaus überwiegen aber imo die Nachteile, die eine Mischung aus OOP und AOP mit sich bringen.

 

[kaesebrot]

AOP ist ne gute Sache, wenn man weiss was man tut. Aber genau da liegt das Problem. Oft weiss man das nicht. Das liegt nicht daran, dass man blöd ist, sondern dass man Code reviewed, den man nicht selbst geschrieben hat.

Gut, aber genauso verhält es sich mit OOP-Code von unerfahrenen OOP-Programmierern.

Und dann fangen die Probleme schon an. Ich kann nun nicht mehr einfach den Debugger nehmen und das Problem so weit wie nötig eingrenzen.

Das ist meiner Meinung nach kein Problem von AOP sondern der IDE-Integrierung. Debugging habe ich noch nicht versucht. ist es wirklich so schlimm? Ich werde es heute mal austesten


viele Grüße,
Käse

 

[SnooP]

Beim Debuggen ist das ähnlich wie mit den Proxies bei Hibernate... - alles nich wirklich prickelnd ... insb. wenn die "Jetzt-Schlage-Zu"-Logik dem Entwickler nicht ersichtlich ist... und nur manchmal der Aspekt zum Tragen kommt, hat man keine Chance zu erkennen, dass da noch was anderes als die sichtbaren Klassen in Erscheinung gerät...

Gut, aber genauso verhält es sich mit OOP-Code von unerfahrenen OOP-Programmierern.

Das ist natürlich richtig - aber insb. weil es heutzutage noch schwer ist erfahrene OOP-Leute zu bekommen, sollte man noch weniger AOP einsetzen, weil das kann erst recht niemand

Also ich würde die Technik doch als sehr tükisch einstufen - auch wenn sie sicherlich Potential hat bzw. das Prinzip als solches nicht völlig abwegig ist