Diskussion:Aspektorientierte Programmierung

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)

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.

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)?

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)

Andere Bedeutung von AOP

AOP kann auch "Advanced Oxidation Process" bedeuten... (nicht signierter Beitrag von Tecklenburg (Diskussion | Beiträge) jpp ?! 15:13, 11. Aug 2006 (CEST))

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)

Rechtschreibung

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

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)