Diskussion:Aspektorientierte Programmierung

message: 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)
thread_title: leichte erklärung

message: 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)
replies: text: 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)
thread_title:  AOP ist eine Notlösung für OOP 

message: 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)
replies: text: Deinen Artikel schaue ich mir gleich an, Danke schon mal. --Marc van Woerkom 15:29, 12. Jan 2005 (CET)
thread_title:  Snake Oil? Jein. 

message: 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)
thread_title:  Ein kleines Beispiel 

message: 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)
thread_title:  Rechtschreibung 

message: 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)
thread_title:  Toter Weblink 

message: 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)
thread_title:  Toter Weblink 

message: 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)
thread_title:  Einleitung 

message: 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)
replies: text: 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)

text: 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)
thread_title:  Kritik am bisherigen Artikel 

message: 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)
thread_title:  Einführendes Beispiel in C, Java und AspectJ 

message: 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)
thread_title:  Beispiel Java gleich AspectJ? 

message: 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)
thread_title:  Entwicklungsstand der aspektorientierten Programmierung 

message: 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)
thread_title:  Beispiel 

message: 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)
thread_title:  Artikel zu lang? 

message: 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)
thread_title:  Zusammenfassung 

message: 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)
thread_title:  template pattern 

message: 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)
thread_title:  Bitte besseres Anwendungsbeispiel angeben 

message: 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)
thread_title:  Python 

message: 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)
replies: text: 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)
thread_title:  NPOV 

message: 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)
thread_title:  Beispiel 

message: 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)
replies: text: 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)
thread_title:  AspectJ Beispiel 

message: 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)
thread_title:  Einführendes Beispiel 

message: 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)
thread_title:  Entwicklungsstand der aspektorientierten Programmierung 

message: – GiftBot (Diskussion) 19:13, 27. Nov. 2015 (CET)
thread_title:  {{Anker|deadurl_2015-10}} Defekter Weblink 

message: 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)
thread_title:  Falsche Source?