Diskussion:Aspektorientierte Programmierung

leichte erklärung

aop ist das kapseln einer methode in einer anderen damit man etwas vor/und/nach dem methodenaufruf tun kann vorauf man sonst keinen einfluss hat. das kann zb. caching,tracing,security sein. welche methode gekapselt wird kann man auch über wildcards bestimmen so dass man nicht für jede zu verändernde methode einen eigene aspect class benötigt. (nicht signierter Beitrag von 86.33.233.198 (Diskussion) 08:04, 30. Jun. 2010 (CEST))

-das ist eine prägnante aber keine "leichte" Erklärung. Sie wirft lauter neue Fragen auf (Wildcards). Eine wirklich gute Definition/Erklärung bezieht sich zudem nur auf sich selbst und nutzt keine Beispiele.--82.83.102.36 23:49, 28. Jul. 2010 (CEST)

ich finde diese Erklärung aber um Welten besser als die im derzeitigen Artikel. -Mifritscher (Diskussion) 16:29, 3. Mär. 2015 (CET)

Geschichtliches und Relevanz

(1) Ich habe heute zum ersten Mal diese Art Programmieransatz kennengelernt. Das scheint auch etwas Interessantes zu sein. Immer gut die WP zu haben.. Aber mir fehlt Information über den Verlauf (Historie) der AOP. Wann ist das entstanden? Wer hat das als erster entwickelt? Gibt es Vorläufer? Wann.. Das würde mich sehr interessieren. (2) Und dann würde ich die tatsächliche Relevanz mehr einschätzen können wollen: Was wurde damit tatsächlich (!) praktisch gelöst, was man sonst nicht so gut hinbekommen hat. Es sind Beispiele enthalten ja, aber ich meine: gibt es wirkliche Anwendungen, die hierauf basieren? (3) Ich wäre vorsichtig mit Aussagen wie "die Akzeptanz wird in den nächsten Jahren da sein " oder so ähnlich. // Ich muss sagen, ich bin schon etwas länger dabei und ich habe schon einige Sachen kommen und gehen sehen, die jeweils alle als das non-plus-ultra angesehen wurden. .. Ansonsten thanx.

Allgemeine Diskussion (Verschiedenes)

"AspectJ z. B. stellt keine vollständig aspektorientierte Lösung dar, weil die Aspektorientierung sich nur auf Klassen beschränkt, die von AspectJ compiliert werden, nicht jedoch für Klassen gilt, die lediglich verwendet werden." - ich finde, dieser Satz ist falsch. "keine vollständig AO Lösung" klingt, als wäre AspectJ keine "richtige" AO-Sprache. Die Begründung dafür finde ich schwer verständlich. Soll das heißen, statisches Weben ist keine "richtige" Aspektorientierung, sondern nur dynamisches Weben? Wenn ja, dann widerspricht das m.E. der allgemeinen Auffassung davon, was Aspektorientierung ist. Davon abgesehen bietet AspectJ seit einer Weile Loadtime Weaving an und benötigt dafür keinen Quellcode. Der Überwachung von Collections dürfte also nichts im Wege stehen. Würde mir jemand zustimmen, den zitierten Satz und den danach zu streichen?

"Sie basiert auf der objektorientierten Programmierung und kann als deren Nachfolgeparadigma angesehen werden." - ist es nicht so, dass erst die kombination wirklich sinnvoll ist. Es ist doch nicht das Ziel nur noch aspekte usw. zu benutzen und alle oo komponenten wieder wegzuwerfen oder? Vielleicht gar nicht so gemeint wie ich es verstehe, aber mit nachfolger assoziiert man ja meist Ablöser.

Ich denke, diese Auffassung kann man sogar im verschärften Maße nur unterstützen: Aspektprogrammierung ist _kein_ eigenständiges Paradigma, sondern vielmehr eine (Sprach-)Erweiterung für einen sehr engen Problemkreis. Meiner Ansicht nach ist "Paradigma" aus dem Artikel zu entfernen. Bitte um Zustimmung und Kommentare. (KL)

Ich vermisse ein einleuchtendes Beispiel.

Das mit dem Logfiles kann doch auch z.B. bei Java mit Interfaces (Schnittstellen) gelöst werden. (Oder habe ich das falsch verstanden?)

Ja, kann man.

Die Verbesserung bei AOP liegt ja darin, das deine Klasse nix von einem Logger wissen muss (also weder ein Interface implementiern, noch eine Logger Instanz erstellen muss). Man kann es wie ein Plugin ansehen ohne vorhandenen Code abändern zu müssen. Die Aspect Klasse greift einfach in die andere Klasse ein, ohne dass die andere Klasse, ja sogar ohne das die Aspekt-Klasse die zu überwachende Klasse mit Namen kennt (Wildcards). Für mich stellt sich dabei allerdings die Frage nach der Sicherheit. Schert sich AOP noch um sowas wie private, protected usw ? --matrixx 11:22, 15.04.2005

Also ehrlich gesagt, verstehe ich nur Bahnhof - und bin wohl nicht der Einzige.Runghold 15:23, 12. Nov 2003 (CET)

Liest sich wirklich wie aus einem Lehrbuch.... und dann war noch ein "Eindeutscher" am Werke. Verschalen mit einer Prise "Weaver" garniert - natürlich alles nicht einführend erklärt. Und als Beispiel einen mathematischen Algorithmus. Quasi als das Häubchen Sahne auf der Komposition der vollständigen Komplexität. Abstrakt sind hier höchstens die Konzepte im Hintergrund (die nicht erklärt werden). TG 01:43, 10. Jul 2004 (CEST)

Habe mal ein weiteren einführenden Abschnitt eingefügt um klar zu machen für was AOP eigentlich gut ist. Hoffe dadurch die Verständlichkeit erhöht zu haben. --Marcobuss 13:31, 11. Jul 2005 (CEST)

Der zentrale Begriff Aspekt wird nicht erklärt, auch was ein Join Point sein soll, kann man nur raten. Ja, es ist ein Buzzword, steht sicher auch in irgendeiner iX erklärt. Durch diesen Artikel allein wird man m.M. nicht verstehen, was das soll. Riecht für mich nach Snake Oil. --Marc van Woerkom 00:03, 11. Jan 2005 (CET)

AOP kam in iX 8/2001, S. 143, jedoch mit C++ und nicht mit AspectJ.

AOP ist eine Notlösung für OOP

Mir fehlt ein Abschnitt in dem klar gemacht wird dass AOP im Prinzip bloss die Funktionalität in OOP-Sprachen wiederherstellen will, die durch das Konzept der Klassenhierarchie in OOP-Sprachen entfernt wurde. Das ist dem Übergang von Baumartigen Verzeichnissen zu Tagging-Netzwerken - die ja auch gleiche Aspekte verschiedener Objekte assoziieren - bei "Web 2.0"-Seiten sehr ähnlich. Ich würde sogar sagen dass das ein ganz allgemeines und global anwendbares Konzept ist, das die breite Masse gerade erst zu entdecken beginnt.

Nichtsdestotrotz besteht das Problem bei funktionalen Programmiersprachen (wie Haskell) nicht, wo sich problemlos mehrere Aspekte aus getrennten Modulen als Interfaces in "Klassen" und damit zu neuen Interfaces zusammenfügen lassen.

(Was fehlt wäre wohl eine Sprache mit der Reinheit von Haskell, der Verfügbarkeit von Bibliotheken, Tools und Dokumentation von C/C++, der Angenehmheit von Ruby und der Leistung/Flexibilität von Ocaml. :)

-- 212.100.46.25 04:17, 29. Jan. 2007 (CET)

Wenn du eine Sprache nimmst, die Mixins unterstützt, bildet das Beziehungsgeflecht zwischen den Typen keinen Baum mehr, sondern einen DAG. Trotzdem ist das noch nicht "aspektorientiert", da z.B. sowas wie das dynamische Umschreiben von Methoden fehlt. AOP ist in diesem Sinne auch -- anders als im Artikel behauptet -- keine "Erweiterung" von OOP, sondern was völlig anderes. Multi io 23:42, 31. Mär. 2008 (CEST)

Snake Oil? Jein.

Ich glaube, ein wesentliches Problem für Autoren bei der Verfassung eines erläuternden Artikels ist, dass man als jemand, der gerade mit aspektorientierter Programmierung beginnt, bisher nur eine vage Vorstellung davon hat, was aspektorientierte Programmierung und die verwendeten Elemente eigentlich wirklich sind. Aspektorientierte Programmierung ist ungefähr so viel Snake Oil wie Objektorientierte Programmierung vor 20 Jahren. Wirklich ausgereifte objektorientierte Programmierung ist in weiter Verbreitung ja auch erst seit ca. 5 Jahren zu finden. Sogar die Entwickler des Java-API mussten selbst erst noch lernen, was OOP wirklich ist, sonst wären solche Design-Fehler wie die Mutability der Klassen java.awt.Dimension und java.util.Date oder das wirklich miese Cloneable nicht passiert. Die möglichen Einsatzgebiete müssen erst noch gefunden werden, ähnlich wie bei der objektorientierten Programmierung. Wer OOP kann, für den sind Sinn und Anwendung einleuchtend, eine gute Erklärung fällt also vergleichsweise einfach. Aber wer kann schon wirklich AOP...

Trotzdem habe ich mal versucht, eine weniger technische, allgemeinverständlichere Erklärung aspektorientierter Programmierung zu geben. Sie ist alles andere als vollständig, genau und präzise. Zerpflückt sie, zerreisst sie, verbessert sie.

Die Java Leute haben auch Nebenläufigkeit noch nicht richtig hinbekommen, schau Dir mal die Änderungen in den Java APIs zu threads an. :-) In der Erlang Gemeinde, die sich bei dem Thema mehr Mühe gegeben haben, findest Du daher einige Leute, die OOP eher ablehnen. Es gibt halt Dinge, für die ist OOP gut, woanders ist es halt nicht die beste Wahl.

Obwohl eher off-topic muss ich sagen du findest genauso gut eine Gemeinde von Menschen die die "Erlang way of Lösen des Problems"^^ grottenschlecht finden, da hier *teilweise* große Geschwindigkeits-Einbüßen gemacht werden müssen. Nicht, dass ich zu dieser Gemeinde gehöre, aber eine andere Perspektive kann manchmal sehr aufschlussreich sein. -- Jerome Baum (nicht signierter Beitrag von 77.176.66.235 (Diskussion | Beiträge) 01:23, 12. Jun. 2009 (CEST))

Deinen Artikel schaue ich mir gleich an, Danke schon mal. --Marc van Woerkom 15:29, 12. Jan 2005 (CET)

Der erste Abschnitt ist echt Müll

Hier wird argumentiert, dass die Aufrufreihenfolge bei der funktionalen Programmierung am leichtesten nachzuvollziehen ist, bei der objektorientierten schon schwieriger und bei der aspektorientierten noch schwieriger. Was ist dann der Vorteil von AOP?

--MauriceKA 10:41, 2. Mär 2005 (CET)

Je umständlicher etwas zu benutzen ist, desto "mächtiger" ist es. Manchmal stimmt diese Aussage sogar. Mit AOP kann man halt manche Sachen wesentlich leichter programmieren, genauso wie OOP mehr kann als COBOL. Manchmal stimmt es nicht, zum Beispiel bei INTERCAL.

--B² 08:08, 26. Mär 2005 (CET)

INTERCAL ist ein gutes Stichwort. Vielleicht hab' ich es ja nur nicht richtig verstanden, aber für mich klingt so ein pointcut nach nichts anderem als einer Implementation des "ComeFrom"-Befehls... mit Wildcards! Und das soll jetzt plötzlich gut sein? Schön, für sowas wie Logging klingt es auf der ersten Blick recht praktisch, aber als grundlegendes Paradigma klingt es für mich nach einem Rezept für heilloses Chaos.... --Brazzy

Ein kleines Beispiel

Einder der entscheidenden Punkte von AOP ist die Trennung von immer wiederkehrender Infratstrukturprogrammierung von der eigentlichen Arbeit. Logging bzw. Tracing ist da ein gutes Beispiel: wenn ich basierend auf den Namen der Methode einen Logeintrag erstellen möchte, muss ich das bei klassischer OO Programmierung entweder über eine Basisklasse und irgendeine Laufzeitinformationsmechanismus lösen, oder in jedem Methodenaufruf entsprechende Loggingeinträge unterbringen. Mit AOP kann ich das Problemlos voneinander trennen und über eine entsprechende Konfiguration steuern. Der Artikel ist etwas abstrakt, wird aber klarer wenn man sich das ganze mal in der Umsetzung anschaut.

--Ebralph 16:19, 15. Mär 2005 (CET)

Objektiviät/Ausgewogenheit

Etwas mehr Objektivität beim Schreiben eines solchen Artikels wäre wünschenswert. So ist es doch etwas weit gegriffen AOP als 'Nachfolgeparadigma' von OOP zu bezeichnen. Fakt ist doch, dass es genauer betrachtet die revolutionären Entwicklungen schon viel früher gab (z.B. in Smalltalk, Self o. Eiffel). Heute werden dies entweder 'abgekupfert' oder eben verbessert - Sie sind aber dennoch nichts Neues. Ein Vergleich von Traits und Aspekten wäre also mitunter sinnvoll und würde die Ausgewogenheit des Artikels verbessern.

Die Aussage "stark polymorphe Programme zeigen erst mit Java oder C# gute Performance, bessere sogar als mit fast jedem C++-Compiler", hätte ich doch gerne mal belegt. Außerdem: Bezieht sich diese Aussage auf die Sprachen Java, C# und C++, die Compiler oder die Laufzeitumgebungen (VM/Nativ)?

Dito. In dieser Form ist es ein typisches Flame-Argument aus einer der unzähligen Java vs. C++-Diskussionen, daher entferne ich es mal.

Schwafel-Laber

ich weiß (nach mehreren Absätzen immer noch nicht, was das ist. Wirklich ein ungewöhnlich schwafelnder Artikel. Und bitte, schreibt keine Artikel über Programmierung, wenn eure Qualifikation in abgepinselten Theoretiker-Folien besteht. "Assembler kapselt Binär in Zeichenketten und befreit den Programmierer von der Maschine", das ist nicht mal mehr witzig.

Dem muss ich zustimmen. Der Author saß wohl zu lange im Marketing-Management. ;)) -- 212.100.46.25 03:59, 29. Jan. 2007 (CET)

Muss dem auch zustimmen. Der gesamte Artikel sollte neu geschrieben werden. Er strotzt nur so von Fehlern, Halbwissen und Redundanzen. --matrixx 21:16, 29. Jan. 2007 (CET)

Ich stimme ebenfalls zu. Hab jetzt schon lange überlegt was "Auch heute noch kranken zahlreiche OO-Programme an Fehlentwürfen bezüglich der Mutability (Zugriffsart) von Attributen und damit unnötigen defensiven Objektkopien." heißen soll und komme nicht drauf. Wenn man sowas schon schreiben muss, sollte es vielleicht auch noch ein bisschen erläutert werden.

Andere Bedeutung von AOP

AOP kann auch "Advanced Oxidation Process" bedeuten... (nicht signierter Beitrag von Tecklenburg (Diskussion | Beiträge) )

Wenn du in einem Halbsatz beschreiben kannst, was das ist, wandle ich die Weiterleitungsseite AOP in eine Begriffsklärung um. --jpp ?! 15:13, 11. Aug 2006 (CEST)

AOP hat im engl. viele Bedeutungen - vieleicht gibts für "Advanced Oxidation Process" ein vorzuziehendes deutsches Äquivalent ? --matrixx 11:07, 13. Aug 2006 (CEST)

AOP ist eine Methode zur Reinigung von Abwasser durch Oxidation der Verschmutzung mit Hydroxylradikalen. Einen deutschen Begriff gibt es da meineswissens nicht. Tecki 19:40, 19. Aug 2006 (CEST)

Ich sehe gerade, dass schon jemand eine Begriffsklärungsseite draus gemacht hat. Dann ist das ja erledigt. --jpp ?! 22:27, 19. Aug 2006 (CEST)

Wieso existiert dafür kein Begriff? Alle drei Wörter lassen sich problemlos übersetzen ohne Probleme mit der Bedeutung zu bewirken. Heraus kommt "fortgeschrittener Oxidationsprozess". Treffend, klar, und logischerweise nicht weniger eindeutig als die englische Variante. Es ginge auch "erweitertes Oxidationsverfahren" oder etwas dazwischen.

Rechtschreibung

Heißt es "aspektorientierte Programmierung", "Aspektorientierte Programmierung" oder "Aspekt-orientierte Programmrierung"? Verschiedene Varianten tauchen im Artikel auf.

Also meines Wissens ist nur die erste Schreibweise korrektes Deutsch. Die Zweite ist nur am Anfang eines Satzes korrekt. Und die Dritte ist schlicht falsch, da hier zusammengeschrieben werden muss. Wenn du magst, ändere alles auf die erste Variante. -- 212.100.46.25 04:22, 29. Jan. 2007 (CET)

Toter Weblink

Bei mehreren automatisierten Botläufen wurde der folgende Weblink als nicht verfügbar erkannt. Bitte überprüfe, ob der Link tatsächlich unerreichbar ist, und korrigiere oder entferne ihn in diesem Fall!

• http://www.ics.uci.edu/~trungcn/jaml/
  • In Aspektorientierte Programmierung on 2007-01-14 19:05:46, 403 Forbidden
  • In Aspektorientierte Programmierung on 2007-01-26 23:12:23, 403 Forbidden

--Zwobot 00:12, 27. Jan. 2007 (CET)

Toter Weblink

Bei mehreren automatisierten Botläufen wurde der folgende Weblink als nicht verfügbar erkannt. Bitte überprüfe, ob der Link tatsächlich unerreichbar ist, und korrigiere oder entferne ihn in diesem Fall!

• http://www.prakinf.tu-ilmenau.de/~hirsch/Projects/Squeak/AspectS/
  • In Aspektorientierte Programmierung on 2007-01-14 19:05:56, 404 Not Found
  • In Aspektorientierte Programmierung on 2007-01-26 23:12:31, 404 Not Found

--Zwobot 00:12, 27. Jan. 2007 (CET)

Einleitung

Ich habe mal versucht, die Einleitung zu verbessern. Bitte schreien, wenn das so nicht akzeptiert wird. Ich werde nachher mal sehen, ob im im Artikel selbst noch etwas beitragen kann. -- Semper 19:54, 4. Jul. 2007 (CEST)

Im englischen Artikel wird sehr schön erläutert was die Motivation hinter AOP ist. Eine OO-Anwendung setzt sich aus mehreren Objekten bzw. Modulen zusammen. Möchte man hier z.B. ein Logging oder eine Fehlerbehandlung integrieren, ist das ein Cross-Cutting Concern. Das Problem schneidet die gesamte Anwendung quer durch und der nötige Quelltext ist über alle Module verteilt. AOP stellt hier eine Lösung zur Verfügung und mehr.

Kritik am bisherigen Artikel

Ich bin der Meinung, dieser Artikel müsste mal gründlich überarbeitet werden.

Bevor ich anfange, hier grössere Änderungen zu machen, hier erstmal eine Übersicht über das, von dem ich meine, dass es geändert werden sollte.

Bitte melden, wenn ich irgend etwas falsch verstanden haben sollte. Meine Kenntnisse im Bereich AOP sind eher theoretischer Art. Ich will also nicht ausschliessen, dass ich das eine oder andere falsch verstanden habe.

Motivation

Hier würde ich eigentlich erwarten, dass erklärt wird, welche Motivation hinter der Entwicklung von AOP steht, d.h. warum ist AOP notwendig, was leisten die bisherigen Paradigmen nicht?

Die hier gemachte Unterscheidung Core-Level-Concerns = Komponenten, System-Level-Concerns = Aspekte halte ich für unsinnig.

Was ist AOP

Ein ziemlich langer Absatz, der sich auf das Thema Kapselung konzentriert - was ja in diesem Zusammenhang nicht falsch ist - aber nur eine einzige direkte Aussage über AOP macht:

Bei AOP handelt es sich um ein Programmierkonzept, welches das Problem der so genannten Cross-Cutting Concern behandelt.

Das ist zwar nicht falsch, aber auch nicht vollständig. Cross-Cutting Concerns sind ein ungelöstes Problem in OOP etc., es ist richtig, dass AOP damit umgehen kann. Das ist aber nicht Essenz von AOP. AOP ist ein Konzept, dass es (im Idealfall) erlaubt, alle Aspekte einer Applikation getrennt zu sehen. Die Behandlung von CCCs ergibt sich daraus.

Einführendes Beispiel in C, Java und AspectJ

void function (Component c) { c.repaint(); }

Für mich ist dieser Artikel der Einstieg in AOP. Als ich dieses Beispiel das erste mal gelesen habe dachte ich zuerst, es sei ein Fehler beim Copy/Paste aufgetreten. Erst im späteren Verlauf des Artikels wird klar, dass der aspektorientierte Teil erst beim Compilerlauf hinzugefügt wird und daher die Methode unverändert bleibt. Das ist natürlich auch der große Vorteil von AOP und die didaktische Wirkung des Beispiels in seiner jetzigen Form ist ziemlich gut, aber vielleicht sollte man darüber nachdenken, ob man hier nicht direkt im Anschluss darauf hinweist, dass man sich erstmal nicht verwirren lassen sollte, dass die Zeile unverändert zum Java-Beispiel erhalten bleibt.

Desweiteren würde ich vielleicht hier schon auf folgenden Umstand hinweisen:

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.

Immerhin gewinnt man hier Modularität auf Kosten der Nachvollziehbarkeit, vgl. z.B. das Attribut "autowire" in Spring. Praktisch, aber bei exzessivem Einsatz wird der Code wieder vollkommen nicht nachvollziehbar und Wartbarkeit ist doch einer der Ansprüche an moderne Softwareentwicklung, oder?

-- Bear Knuckle 10:40, 10. Dez. 2008 (CET)

Beispiel Java gleich AspectJ?

Irgendwie redundant, vielleicht ein Beispiel entfernen und nur auf Gleichheit des geschriebenen Codes hinweisen? Gibt es hier Consensus? -- Jerome Baum (nicht signierter Beitrag von 77.176.66.235 (Diskussion | Beiträge) 01:23, 12. Jun. 2009 (CEST))

Erklärung als Ableitung von prozeduraler und objektorientierter Programmierung

Dieser Absatz enthält fast nur die Erklärung, dass die Nachvollziehbarkeit der Programmausführung von prozuderaler Programierung über OOP nach AOP immer mehr nachlässt. Nichts was wirklich der Erklärung der AOP dient.

Der Beispielcode für die AspektJ-Implementierung ist nicht von der Java-Implementierung zu unterscheiden. Die ganze Erklärung auf Basis von AspectJ ist ohne Kenntnisse in AspektJ nur sehr schwer verständlich - und damit also ziemlich sinnlos, zumal sie sich AspektJ-spezifischen Details verliert.

Die angeführte Analogie finde ich ziemlich gut, sollte aber vielleicht etwas anschaulicher sein. Ich weiss nicht, ob sie verständlich ist, wenn das ganze Wissen des Lesers über AOP sich auf den bisherigen Artiel beschränkt.

Die technische Betrachtung ist teils unnötig (muss der Leser hier wirklich etwas über Spungvektoren als mögliche Implementierung erfahren?), teils falsch: Es ist nicht ein Objekt C in der Lage, Interaktionen zwischen zwei Objekten A und B zu überwachen, sondern - durch den Code-Eingriff - eine Klasse C die Interaktionen zwischen den Klassen A und B.

Dieser Fehler führt uns direkt zu

Einsatzgebiete

Mein erste Eindruck war: dieser Abschnitt ist komplett falsch. Überall, wo hier von Objekten die Rede ist, sind in der AOP Klassen betroffen. Die Aussage, AOP könne Eventhandling komplett ersetzten stimmt damit nicht. Eventhandling ist dynamisch: ein Objekt bestimmt zur Laufzeit, für welche Objekte es Listener sein will. AOP wie es im Artikel bis hierhin dargestellt wird, stellt die Verbindung statisch zur Compilezeit her.

Weiter unten im Artikel wird auch das Thema "AOP auf Objektebene" kurz erwähnt. Damit könnten diese Aussagen stimmen (obwohl ich auch dann noch ziemliche Bedenken hätte: Eventlistener stellen eine Abstraktion her, die man bei direkter Modifikation der Objekte aufgeben würde.)

Zumindest mit dem hier dargestellten Tools ist die generelle Aussage AOP ersetzt Event-Listener falsch.

Es gibt bestimmte Anwendungsgebiete, wo AOP-Mechanismen anstelle von Eventhandling verwendet werden können, aber von komplett ersetzen kann auf keinen Fall die Rede sein.

Ansonsten wird als einziges weiteres Anwendungsgebiet das Testen und Tracen aufgeführt. Hier müsste das Thema doch noch einiges mehr hergeben.

Entwicklungsstand der aspektorientierten Programmierung

Dieser Abschnitt erwähnt nur AspektJ als Implementierung, und die theoretische Betrachtung beschränkt sich auf die Frage, wie AOP auf Objektebene funktionieren könnte.

In Anbetracht der in Cross-Cutting Concern angegebenen Literaturliste lässt sich hier sicher noch etwas mehr sagen.

"Ebenso kann es zu einem Versiegen von Neuentwicklungen im AOP Bereich kommen, wenn die höhere Abstraktion in der Praxis nicht von einem ausreichenden Anteil von Entwicklern verstanden und eingesetzt wird." <- nicht objektiv, ein Versiegen kann auch vorkommen, wenn diese Art der höheren Abstraktion nur nicht akzeptiert wird; es ist nicht nötig, dass es nicht verstanden wird. KoH - 92.202.58.200 04:12, 16. Dez. 2008 (CET)

Joinpoint vs. Joinpoint shadow

Hier wird auf einen speziellen Aspekt von Joinpoints eingegangen, die bisher nur in einem Nebensatz erklärt wurden. Ich meine, dieser Abschnitt kann komplett weg.

Beispiel

Ein Beispiel ist sicher nötig, aber bitte, muss es denn wirklich das totgetretene Thema Tracing sein? Egal wo man in der Presse oder sonstwo etwas zum Thema AOP liest, es wird Tracing als strahlendes Beispiel hingestellt.

Zum einen ist Tracing bzw. Logging in dieser Form fast nutzlos (schon mal mehere GB "entering function" / "exiting function" versucht zu interpretieren?) Tracing muss selektiv erfolgen, oft mitten in einer Methode, und es müssen in der Regel weitere Informationen (Variableninhalte etc.) mit ausgegeben werden. Beides sind grosse Probleme beim Tracing in der gezeigten Form. (zumindest habe ich noch kein Beispiel gesehen, das in irgendeiner Form praxisgerecht ist)

ACK. Man sollte vielleicht sowas wie Zugriffskontrolle, automatisches Transaktionsmanagement oder Change-Event-Feuerung als Beispiele verwenden, das leuchtet eher ein. Man könnte auch kurz andeuten, wie man durch Kombination dieser (orthogonalen) Aspekte sowas wie eine einfache Datenzugriffsschicht ohne viel redundanten Code generieren lassen kann. Sowas würde das Ganze recht gut motivieren, denke ich. Multi io 23:58, 31. Mär. 2008 (CEST)

Zum anderen lässt die ständige Beschränkung der Beispiele auf das Logging oder Tracing Zweifel am Sinn der AOP aufkommen: Ist das wirklich mehr als ein neues Loggingframework?

Davon abgesehen ist das Beispiel verständlich.

Die jetzt folgende Erklärung von Pointcuts sollte vielleicht vorgezogen werden. Auch wird hier wieder von Join-Points geredet, ohne sie ausreichend zu erklären.

---

Das "Beispiel in AspectJ: void function (Component c) { c.repaint(); }" ist genau gleich mit dem "Beispiel in Java: void function (Component c) { c.repaint(); }" - daher ist dieses Beispiel eher verwirrend als weiterführend um AspectJ mit einem Beispielcode vorzustellen.

Typische Aufgaben

Abgesehen davon, dass dieser Abschnitt thematisch dem weiter oben schon abgehandelten Thema Einsatzgebiete entspricht, wird wieder die Beschränkung auf Cross-Cutting Concerns hergestellt. Das mag zwar der momentane Stand von AspektJ sein, ist aber in dieser Einschränkung sicher nicht auf das grundsätzliche Konzept AOP zutreffend. Das ist, als würde man behaupten, der Hauptzweck von Objektorientierter Programmierung sei die Wiederverwendung von Code.

Zukünftige Entwicklung

Vielleicht könnte man hier noch ein paar fachliche Punkte nennen: wo geht die Entwicklung thematisch hin?

Fehlende Punkte

Folgendes habe ich im Artikel vermisst:

• Einbettung von AOP in AOSD (Aspect Oriented Software Development), d.h. einen Blick über den Tellerrand des reinen Codes hinaus
• Verschiedene Ansätze zumindest erwähnen. Es gibt mehr als nur AspektJ.
• Eine Übersicht über das Vorgehen bei AOP: Wie sieht die Schnittstelle zwischen Aspekten aus, wie werden die Aspekte logisch in den Code eingeklinkt.
• Grenzen der aktuellen Technik aufzeigen. (z.B. die starke Beschränkung der Definition von Join-Points)

Artikel zu lang?

Zu überlegen wäre überhaupt, ob der Artikel in dieser Länge sinnvoll ist, oder ob eine Übersicht über das Thema, wie es z.B. Objektorientierte Programmierung gibt, sinnvoller wäre? Vielleicht kann man einzelne Theman in eigene Artikel auslagern?

jep, aber das ist bei wikipedia generell so die vereinigen lieber mehrere klar getrennte kleine Artikel zu einem großen verwirrenden ... wohl um keywörter zu sparen , denn es gibt hier keine taxonomischen links sondern alle artikel bevölkern die selbe ebene (nicht signierter Beitrag von 79.247.180.231 (Diskussion | Beiträge) 15:34, 8. Mai 2009 (CEST))

Zusammenfassung

Wenn kein Einspruch kommt, werde ich mal versuchen, den Artikel in den nächsten Tagen entsprechend umzubauen. Da das eine grössere Sache wird, werde ich das wohl eestmal bei mir im User-Namenraum machen. Wenn ich angefangen habe, werde ich hier den Link auf die Baustelle posten.

-- Semper 17:49, 7. Jul. 2007 (CEST)

template pattern

pointcuts entsprechen hooks! (abgesehen von der impliziten und expliziten definition)

trifft diese aussage zu? bzw. eine erklärung der unterschiede währe gut. (nicht signierter Beitrag von 79.247.180.231 (Diskussion | Beiträge) 15:34, 8. Mai 2009 (CEST))

Bitte besseres Anwendungsbeispiel angeben

In dem Buch Spring 3 von Eberhard Wolff ISBN 978-3-89864-572-0 gibt es ein recht umfangreiches Kapiel, wie AOP in Spring eingesetzt wird. Genau wie in diesem Wikipedia Artikel, beschreibt auch dieses Buch das Trace-Logging als Paradebeispiel. Aber genau mit diesem Anwendungsbeispiel habe ich meine Probleme. Denn Trace-Logging benutze ich, um Fehlfunktionen zu analysieren. Dabei interessiere ich mich kaum für die Reihenfolge, in der Prozeduren aufgerufen werden, denn die kenne ich als Programmierer bereits, bevor das Programm überhaupt gestartet wird.

Zwischengedanke: Es sei denn, ich steure den Programmablauf mit AOP, dann ist er nicht mehr aus dem Quelltext ablesbar. Dann könnte ich mit Aspekten die Funktionsaufrufe Tracen, um so den Programm-Ablauf festzustellen. Hier wäre AOP dann scheinbar die Lösung für ein Problem, dass ohne AOP nicht existieren würde. Zurück zum Thema:

Vielmehr interessiere ich mich beim Tracing für die Inhalte von Variablen und für die Ergebnisse von Vergleichen innerhalb von Funktionen. Ich will wissen, warum sich das Programm bestimmte Code-Zweige entschieden hat und welche temporären Zwischenergebnisse zu einem bestimmten Rückgabewert einer Funktion führten.

Soweit ich dieses AOP Thema verstanden habe, kann mir AOP nicht dabei helfen, diese Informationen zu loggen. Ich werde wohl nach wie vor einen statischen Logger brauchen, dessen Aufruf ich in den funktionalen Code einfüge. Nun fehlt mir leider immer noch ein einleuchtendes Beispiel für den Nutzen von AOP.

Momentan fürchte ich eher, daß Entwickler B den Aspekt orientierten Code von Entwickler A nur mit umfangreicher textueller Dokumentation nachvollziehen kann. Da Programmierer aber aus Unternehmerischer Sicht austauschbar sein sollten, widerspricht AOP möglicherweise den Interessen des Unternehmens, das Programmierer beschäftigt.

Kann mir jemand ein praktischeres Anwendungsbeispiel für den Nutzen von AOP nennen? Was halten andere Entwickler von meinen Befürchtungen bezüglich der Nachvollziehbarkeit?

-- 62.143.216.9 10:07, 7. Mär. 2010 (CET)

Python

Python ist eine etablierte (Skript)sprache, welche aspektorientierte Entwicklung unterstützt. Das sollte in jedem Fall erwähnt werden. Allerdings bin ich mir über das Ausmaß der Unterstützung noch nicht ganz im Klaren. Das "Verweben" erfolgt doch im Gegensatz zu AspectJ nativ, oder? Vielleicht kann ja noch jemand etwas dazu beitragen, der hier tiefer in der Materie steckt. --naraesk 02:41, 10. Nov. 2010 (CET)

NPOV

Zumindest dem Abschnitt Aspektorientierte Programmierung#Entwicklungsstand der aspektorientierten Programmierung fehlt der neutrale Standpunkt bzw. zumindest Belege. Nur weil AspectJ nicht 100% AOP kann heisst das ja nix (Java ist auch nicht 100% OO, darum steckt OO ja auch nicht in den Kinderschuhen). Der Abschnitt geht auch davon aus, dass AOP ein dominantes Programmiersprachenparadigma sein möchte (und dieses Ziel noch nicht erreicht hat). Ich denke nicht, dass das ein Ziel von AOP ist. Der ganze Abschnitt ist mMn ziemlich persönlich gefärbtes Geschwafel. --Sebastian.Dietrich ✉ 09:36, 10. Nov. 2010 (CET)

Volle Zustimmung. Das tut richtig weh. „Außerdem ist strittig“, „Eine Lösung könnte“, „dürften noch einige Jahre und Programmiersprachen ins Land gehen“. Da braucht es nicht nur Quellen, sondern eine völlig neue Fassung. Überhaupt finde ich es fraglich, bei einem Paradigma von einem "Entwicklungsstand" zu sprechen. --Zahnradzacken 10:12, 10. Nov. 2010 (CET)

Beispiel

Sollte im Abschnitt "Beispiel in AspectJ:

void function (Component c) {

   c.repaint(); 

}

" nicht anderer Code stehen. Hier wiederholt sich der C-Code. (nicht signierter Beitrag von 178.1.213.190 (Diskussion) 19:58, 12. Mai 2012 (CEST))

Und das ist jetzt im November immer noch genau so falsch wie im Mai. Gibt es keinen, der sich damit auskennt??? --193.41.135.69 18:03, 15. Nov. 2012 (CET)

Das Beispiel stimt soweit schon, es wird je nachdem was für ein Objekt c wirklich ist eine andere Methode aufgerufen, während beim C-Code immer dieselbe Funktion verwendet wird. Das Beispiel ist also legitim, wobei ein "Nicht-OOP"-Programmierer wohl wenig damit anfangen kann. --194.208.35.47 13:18, 20. Dez. 2012 (CET)

AspectJ Beispiel

Da dies ein Wiki-Artikel ist und somit für jedermann erischtlich und mehrheitlich verständlich sein sollte, fehlt hier die Erläuterung dennoch, da das Coding eben identisch ist. Ein eindeutiger Bezug, der den Unterschied erläutert wäre angebracht bis notwendig. (nicht signierter Beitrag von 94.126.74.17 (Diskussion) 15:58, 13. Aug. 2013 (CEST))

Da dies ein Wiki-Artikel ist und somit von jedermann verbessert werden kann, wärs toll wenn du das machst :-) WP:Sei mutig --Sebastian.Dietrich ✉ 17:47, 13. Aug. 2013 (CEST)

Einführendes Beispiel

Im "Einführendes Beispiel" wäre es gut schon zu sehen, dass die Klasse offensichtlich AOPDemo heißen soll - Eine kleine Erklärung/Anmerkung, was genau pointcut traceCall(): call(* AOPDemo.*(..)); macht wäre auch gut - was machen die Sterne, was die (..) - Ist das nur eiin Platzhalter? (nicht signierter Beitrag von 5.28.117.161 (Diskussion) 12:40, 10. Dez. 2013 (CET))

Entwicklungsstand der aspektorientierten Programmierung

Die aspektorientierte Programmierung steckt heute noch in den Kinderschuhen. AspectJ z. B. stellt keine vollständig aspektorientierte Lösung dar, weil die Aspektorientierung sich nur auf Klassen beschränkt, die von AspectJ compiliert werden, nicht jedoch für Klassen gilt, die lediglich verwendet werden. Das besonders interessante Einsatzgebiet der Überwachung von Collections ist damit nur sehr eingeschränkt möglich.

Ein anderes Konzept verfolgt die inzwischen eingesetzte Scriptsprache gwX-Script, bei der nur bewusst vom Framework deklarierte Concerns mehrfach von "Packs" (meistens Erweiterungen) ausgefüllt werden können. Damit lässt sich ein nativer Plugin-Ersatz schaffen, der ein Patchen des Hauptprogramms für ein neues Feature unnötig macht.

Außerdem ist strittig, ob und wie aspektorientierte Programmierung auf Objekt-Ebene zu realisieren ist. Schnell, aber enorm speicherintensiv sind Patchlisten für jedes einzelne Objekt. Eine Lösung könnte die Einführung einer Methodeneigenschaft „controllable“ oder „aspect“ sein, welche als Join-Point verwendbare Methoden kennzeichnet, vergleichbar mit „virtual“ in C++, das polymorphe Methoden kennzeichnet. Jedoch zeigen einerseits moderne OO-Sprachen wie Java auf Objektebene ausschließlich virtuelle Methoden, was ein Indikator dafür ist, eine solche Einschränkung nicht einzuführen, andererseits ist eine derartige Einschränkung wider die Natur der aspektorientierten Programmierung. Andere Ansätze, wie AspectJ, beschränken sich auf die Aspektorientierung auf Klassenebene, die gezielte Überwachung bestimmter einzelner Objekte ist nicht deklarativ möglich.

Bis sich die aspektorientierte Programmierung zu einem dominierenden Programmierparadigma wie heute die objektorientierte Programmierung entwickelt hat, dürften noch einige Jahre und Programmiersprachen ins Land gehen. AspectJ ist dabei mit den ersten OO-Schritten in C vergleichbar, aus denen später Objective C und C++ hervorgegangen sind. Man kann davon ausgehen, dass sich auf der Basis der objektorientierten Programmiersprachen Java und C# aspektorientierte Programmiersprachen entwickeln werden, wie einst Oberon und C++ aus Pascal und C entstanden sind. Diese werden den Programmierern ermöglichen, die Aspektorientierung zu erkunden, aspektorientierte Programmiermuster zu entwerfen und schließlich zur Entwicklung ausgereifter aspektorientierter Sprachen und Laufzeitumgebungen führen, wie heute Java oder C# für die Objektorientierung.

Ebenso kann es zu einem Versiegen von Neuentwicklungen im AOP-Bereich kommen, wenn die höhere Abstraktion in der Praxis nicht von einem ausreichenden Anteil von Entwicklern verstanden und eingesetzt wird. Aktuell werden bereits OO-Techniken häufig nicht im Sinne der ursprünglichen Konzeption, sondern ausschließlich zur Erfüllung von Vorgaben eingesetzt. Vor diesem Hintergrund ist das Potential für noch weiter abstrahierende Techniken ungewiss.

Nachdem also über 4 Jahre lang keiner geschafft hat, einen vernünftigen Abschnitt "Entwicklungsstand" ohne viel Konjunktiv zu beschreiben, wird es sicherlich auch nicht so schnell passieren. Ganz zu schweigen davon, dass es aktuell gehalten werden muss. Falls sich alse doch jemand mit etwas Lust und Ahnung erbarmt, der gelöschte Text steht oben... --LC-de (Diskussion) 14:50, 7. Apr. 2015 (CEST)

Defekter Weblink

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieses Fehlers finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://www.theserverside.de/funf-wege-der-fehlersuche-in-java/
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Serverproblem (HTTP-Statuscode 500) andere Artikel, gleiche Domainhttp://giftbot.dwl.invalid/http://www.theserverside.de/funf-wege-der-fehlersuche-in-java/

– GiftBot (Diskussion) 19:13, 27. Nov. 2015 (CET)

Falsche Source?

Unter "Ableitung aus früheren Paradigmen" gibt es drei Source-Beispiele. Das dritte ist allerdings das gleiche wie das zweite. Meine Vermutung ist ein Paste'n'Copy-Fehler, oder sieht AspectJ genauso aus wie Java? (nicht signierter Beitrag von Christianpackeniuscom (Diskussion | Beiträge) 11:22, 7. Apr. 2017 (CEST))