Diskussion:Aspektorientierte Programmierung

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)

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.

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)

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 mittunter sinnvoll und würde die Ausgewogenheit des Artikels verbessern.