Vor kurzem habe ich etwas über AspectC++ gelesen. Das hört sich alles ziemlich interessant an. Nur: Setzt das auch jemand in der Praxis ein?
Kennen ja, benutzen nein. AOP hört sich gut an, geht aber mmn an der Realität vorbei. Ich habe auch noch nie ein wirklich überzeugendes Beispiel gefunden, das meiste sind Konstrukte wie "Logging von Funktions Einsprüngen" o.ä., aber wer macht das den? Das ist aufgabe des Debuggers/Profilers, ich will nicht aus einer Logdatei rausuchen (unter Millionen Einträgen wenn jeder Funktionsaufruf "Aspektorientiert" geloggt wird) wann welche Funktion aufgerufen wurde. Zweites Beispiel ist Transaktionssteuerung, auch hier hängt es schnell wenn nicht jede Funktion eine implizite Transaktion ist, außerdem geht sowas über Container/Contexe sehr viel intuitiver. Wiederverwendbarkeit erhält man auch besser durch geeigente Modularisierung und Schnittstellenbildung, auch hat man seltens jemanden der "für Logging" zuständig ist, ein gewisser Überblick über die Architektur ist sowieso nötig um nicht zu stark aneinander vorbei zu entwickeln. In meinen Augen der größte Knackpunkt: Für AOP benötigt man meistens eine Sprache oder einen speziellen Compiler/Preprozessor welcher auf der eigentlichen Zielsprache aufsetzt -> Zusätzliche Komplexität, mäßige Toolunterstützung, Aufwand bei den Build und Prozesswerkzeugen.
Hmmm, zuerst dachte ich ja das wäre eine Abstraktionebene höher ähnlich wie UML, dann habe ich das hier überflogen http://aspectc.org/Home.1.0.html und ganz ehrlich wozu brauche ich zusätzliche "Pseudoerweiterungen" in C++ wenn ich mein aktuelles Projekt ohne Probleme einfach objektorientiert darstellen kann ? Eine STL z.B. dient dazu die Entwicklung zu beschleunigen und übersichtlicher zu gestalten das Konzept hier ist wohl eher gegenteilig ... Läubi .. schrieb: > das meiste sind Konstrukte wie "Logging von Funktions > Einsprüngen" o.ä., Tja das Konzept ist halt keine wirklich Hilfe beim programmieren, hätte man sich da an Eiffel o.ä. angelehnt würde ich ja noch einen Sinn darin sehen den Code automatisch zu überprüfen und grobe Schnitzer vom Compiler aufzeigen zu lassen, nur ist sowas ja gar nicht vorgesehen ... Aber es gibt halt nix was es nicht gibt ...
@kopfkratzer Mit aspektorientierter Programmierung ist es möglich, die technischen und funktionellen Aspekte bei der Programmierung voneinander logisch zu trennen.
Ich hatte schon länger nichts mehr mit C++ zu tun. Bin aber seit Jahren intensiv mit Java beschäftigt. Und da wird es sehr stark eingesetzt und vor allem sehr konstruktiv. Ich verweise nur mal auf Hibernate oder Spring. Dort wird sehr vieles deutlich einfacher durch AOP und Annotations.
@Dieter Meinst du AspectJ? Das hört sich interessant an, welche Vorteile erzielt man dadurch konkret?
Ulli schrieb: > @Dieter > Meinst du AspectJ? Das hört sich interessant an, welche Vorteile erzielt > man dadurch konkret? Hi Ulli, ich kann Dir leider keine qualifizierte Antwort dazu gebe. Ich benutze es idR. nur. Sprich, sobald Du Klassen und Methoden mit Annotations versiehst, benutzt Du bereits AOP.
Ulli schrieb: > @kopfkratzer > Mit aspektorientierter Programmierung ist es möglich, die technischen > und funktionellen Aspekte bei der Programmierung voneinander logisch zu > trennen. Interessant und was sind nun die technischen und die funktionellen "Aspekte" ? Definition(en) laut deutscher WIKI: http://de.wikipedia.org/wiki/Aspekt Und wenn ich dann da auf die "Programmierung" gehe fällt mir dieses Wort sofort auf "Geschäftslogik" ... Der Ansatz soll sein "geschäftliche" Dinge von Anfang an im Programm zu haben damit wie Läubi schon schrieb ich als "Top-Manager" sicher sein kann die "vollständige Kontrolle" über die Programmierung und das Programm zu haben (durch "lückenlose" Dokumentation was wann wo wie geschieht). Sowas funktioniert aber genausowenig wie die "Klickibunti" Programmierschnittstellen und die GB großen vorgefertigten Bibliotheken die teuer von genannten "Top-Managern" eingekauft werden, um "standardisiert" und "uptodate" zu sein. Logs die nicht transparent machen können welche reale Logik innerhalb des Programmes abläuft sind genauso sinnvoll wie die Transferlogs die z.B. bei SAP anfallen und genau aus dieser Schiene kommt das wohl. Statt also etwas sinnloses einzubauen sollte man als "Top-Manager" einfach in der Lage sein seinen Job zu machen und den Gehirnschmalz am ANFANG eines Projektes zu massieren, denn wenn man dadurch ein gutes Konzept mit passenden Ausstiegspunkten bei Fehlentwicklungen (die NIE auszuschließen sind) bekommt hat man später keinen Ärger. Denn was nützt mir denn die "lückelose" Dokumentation über das Versagen meines Konzepts ?
Ulli schrieb: > Setzt das auch jemand in der Praxis ein? Ja, und zwar AspectJ für einen ziemlich exotischen Fall: Es gibt eine Library, welche verwendet werden muss, aber der Source ist nicht vorhanden. Und diese Library hat Bugs. Zum Flicken von Fehlern wird mit AspectJ Code hineingemischt, welcher Parameter flickt usw. Aber für diesen Anwendungsfall war es wohl nicht wirklich gedacht, es sei denn, man sieht Fehlerfreiheit als technischen Aspekt an :-) Dieter Engelhardt schrieb: > Sprich, sobald Du Klassen und Methoden mit > Annotations versiehst, benutzt Du bereits AOP. Das stimmt m. A. nach nicht. Du meinst Annotations, das geht in Richtung Meta-Daten oder Meta-Programmierung. AspectJ ist etwas anderes, das ändert den byte code - da wird nachträglich Code eingefügt.
AOP und Annotations gehören zusammen: AOP provides a unique way of encapsulating behavior and applying it transparently to your application code. If you combine it with annotations, you basically have a very structured, simple way of extending the Java language. The annotation is the syntax, and the aspect provides the functionality for that aspect. This chapter walks through detailed examples on how you can use AOP and annotations to turn your frameworks into Java language features. Hier mehr dazu: https://docs.jboss.org/aop/1.0/aspect-framework/userguide/en/html/annotations.html
Roland H. schrieb: > Ja, und zwar AspectJ für einen ziemlich exotischen Fall Also gewissermaßen als komfortablen byte-Code enhancer ;-) Dieter Engelhardt schrieb: > AOP und Annotations gehören zusammen Sagen wir mal so, es vereinfacht es etwas, aber Annotations sind nicht AOP! AOP würde auch ohne Annotations funktionieren. Dieter Engelhardt schrieb: > Hier mehr dazu Das erste Beispiel lass ich gerade mal noch durchgehen, obwohl es mies programmiert ist und auch wieder nur für wenige spezielle Anwendungsfälle brauchbar. Beim zweiten Nimmt es der Autor auch nicht sooo genau, am Anfang heißt es: >> Annotations are a new feature of JDK 5.0 ... soweit so gut, im folgendem dann: >> Sure, you could use a ThreadLocal variable directly, >> but the problem with ThreadLocal is that it is untyped Aha... eventuell hätte er mal vorher nicht beim lesen der Docs für 1.5 bei A wie Annotation aufgehört hätte er gesehen, dass natürlich ThreadLocal typisiert ist: http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/ThreadLocal.html also mal wieder ein konstruiertes Beispiel, was man in der Praxis weder braucht, noch ist das allgemeingültig. Das dritte Beispiel ist auch wieder reiner Selbstzweck, es wird eine Funktion "nachgebaut" welches es schon in vielen Frameworks oder Applicationservern gibt, in wie fern dies mit solchen Interferriert wenn ich einen Typ dann wieder nach meinem gut dünken behandle lässt der Autor offen, in der Praxis müsste ich außerdem für jeden Typ wieder einen neuen Aspekt programmieren, d.h. der Programmierer muss wissen welche Typen überhaupt für diese Annotation erlaubt sind... Das Problem ist einfach: Klar kann ich mit den Methoden von AOP und einem passendem Framework einzelne Aufgaben (eventuell auch etwas eleganter) lösen, aber von einem Programmierparadigma ist man dann weit entfernt und AOP ist (entgegen seines Anspruchs) bestenfalls ein Werkzeug oder Entwurfsmuster für exotische Randbereiche. Demgegenüber steht die zusätzliche Komplexität wie oben schon angesprochen um mal bei dem Link zu bleiben: Ich brauch die AOP Sprache, ich brauch eine XML Datei und ich brauch das JBoss AOP Framework was fröhlich meine Klassen verändert und ggf. so integrationsprobleme mit anderen Frameworks oder Debuggingwerkzeugen hervorruft.
Dieter Engelhardt schrieb: > AOP und Annotations gehören zusammen: Nicht zwingend. Es gibt "Spring AOP" und "JBoss AOP", ich kenne allerdings kein "Hibernate AOP" in dem Sinne, dass dort unter der Haube aspectj zum Einsatz kommt. Es gibt aber Spring, JBoss (bzw. EJB) und Hibernate auch ohne AOP im Sinne der Verwendung von aspectj. Meinetwegen sind dann Reflection, dynamic proxies, instrumentation oder der Einsatz von CGLIB implizit auch AOP, aber diese Dinge finden hauptsächlich zur Laufzeit statt (und nicht wie bei aspectj zur Compile-Zeit). Du sprichst davon, dass es "stark eingesetzt" wird, und dass aus der Verwendung von Annotations automatisch AOP folgt bzw. beides zusammengehört. Das letztere eher nicht, denn Meta-Daten/Meta-Programmierung ist eigenständig. Oder was hat ein @Override, @Deprecated oder ein JPA @SequenceGenerator mit AOP zu tun? "Starker Einsatz" im Sinne von Reflection, dynamic proxies etc. meinetwegen. Auf meinem Radar findet explizites AOP im Sinne von "Spring AOP", "JBoss AOP", "pointcuts" oder aspectj nur spärlich statt. Zeig doch mal ein Beispiel, wo Du aktiv oder passiv AOP einsetzt.
Roland H. schrieb: > Dieter Engelhardt schrieb: >> AOP und Annotations gehören zusammen: > > Nicht zwingend. > Ich räume ein, dass ich AOP mit Annotations verwechselt habe. Da muß ich wohl noch ein paar Hausaufgaben machen.
Läubi .. schrieb: > Also gewissermaßen als komfortablen byte-Code enhancer ;-) Genau. Und das ganze war auch so nie geplant. Man hat einfach bei der Fehlersuche mit aspectj das Tracing "hineingewoben", und dann bemerkt, dass man so den Fehler auch korrigieren kann. Immerhin hat es den Produktionsstatus erreicht, aber meilenweit vom AOP-Anspruch entfernt :-) Läubi .. schrieb: > Demgegenüber steht die zusätzliche Komplexität wie oben schon > angesprochen um mal bei dem Link zu bleiben: Ich brauch die AOP Sprache, > ich brauch eine XML Datei und ich brauch das JBoss AOP Framework was > fröhlich meine Klassen verändert und ggf. so integrationsprobleme mit > anderen Frameworks oder Debuggingwerkzeugen hervorruft. Dem ist aus meiner Sicht auch nichts mehr hinzuzufügen, außer dass man sich im Falle von JBoss AOP auch noch an den Applikationsserver bindet. Das wiederum ist ein Aspekt der Kundenbindung, insofern passt es wieder :-) Ich habe ein paar Anläufe mit aspectj hinter mir, aber irgendwie hat es nie gezündet. Insofern würden mich schon produktive Einsätze interessieren.
Roland H. schrieb: > Ich habe ein paar Anläufe mit aspectj hinter mir, aber irgendwie hat es > nie gezündet. Insofern würden mich schon produktive Einsätze > interessieren. http://en.wikipedia.org/wiki/COMEFROM#Practical_uses SCNR
Interessant an AOP finde ich vor allem, daß das von Gregor Kiczales kommt. Der hat im Prinzip die Metaobjektfähigkeiten aus seinem Buch und dem Common Lisp Object System nach Java portiert.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.