Diskussion:Decorator

message: Im Beitrag erscheint: "...da der Aufrufende gar nicht mitbekommt, dass ein Dekorierer vorgeschaltet 
ist.".
Mein Problem: Wer ist der Aufrufende? bzw. Wie ist das zu verstehen?
Nach dem einfachen Java-Beispiel muss ein Aufrufer (z.B. Sie/Du) den Dekorierer aufrufen/instanziieren, also auch kennen (um ggf. schnittstellenkompatible, bereits konstruierte (oder gerade konstruierte) Objekte zu übergeben).
Wenn ich z.B. http://homepages.fh-giessen.de/~hg7132/swt/skr9910/einausgabe.html richtig verstehe, kann der Aufrufende sowohl auf die Kernfunktionalität als auch auf die dekorierte Funktionalität zugreifen. Er bekommt das Vorschalten eines Dekorierers also nicht nur mit, sondern er kontrolliert das selbst. --Ralf Detzler 03:37, 8. Feb 2006 (CET)
replies: text: Ich denke es ist gemeint, daß sich das Interface nicht ändert, was aber nur eine Grundeigenschaft von Vererbung ist. Mal sehen ob ich es umformulieren kann.--Kilessan 17:51, 29. Sep. 2007 (CEST)

text: An der Aufrufstelle meinVerhustetesMonster.Drohe() ist der Typ des verhusteten Monsters einfach Spielfigur, d.h. dort sieht der Quelltext-Code nichts von einem dekorierten Objekt, sondern nur eine Spielfigur. Diese Spielfigur könnte auch als Referenz an eine Funktion übergeben worden sein, in der dann figur.Drohe() steht, d.h. spätestens der Schreiber dieser Funktion sieht nichts mehr vom Dekorierer. --Wikiplex 16:26, 16. Aug. 2009 (CEST)
thread_title:  Aufrufer sieht Dekorierer nicht? 

message: Der Artikel enthält ein Bild, dem eine Bildbeschreibung fehlt, überprüfe bitte, ob es sinnvoll ist, diese zu ergänzen. Gerade für blinde Benutzer ist diese Information sehr wichtig. Wenn du dich auskennst, dann statte bitte das Bild mit einer aussagekräftigen Bildbeschreibung aus. Suche dazu nach der Textstelle  und ergänze sie.
:Wenn du eine fehlende Bildbeschreibung ergänzen willst, kannst du im Zuge der Bearbeitung folgende Punkte prüfen:
:* Namensraum Datei: Bilder sollte im Namensraum Datei liegen. Bitte ändere die alten Bezeichnungen Bild: und Image: in Datei:.
:* Skalierung: Außerhalb von Infoboxen sollten keine festen Bildbreiten (zum Beispiel 100px) verwendet werden. Für den Fließtext im Artikelnamensraum gibt es Thumbnails in Verbindung mit der automatischen Skalierung. Um ein Bild/eine Grafik in besonderen Fällen dennoch größer oder kleiner darzustellen, kann der „upright“-Parameter verwendet werden. Damit erfolgt eine prozentuale Skalierung, die sich an den Benutzereinstellungen orientiert. --SpBot 21:57, 1. Mär. 2009 (CET)
thread_title: Bildbeschreibung fehlt bei ''<nowiki>[[Bild:Dekorierer.png]]</nowiki>'' 

message: Mir scheint, das ist generell falsch, denn sowohl in den mir bekannten Implementationen wird eine 'benutzt' Beziehung verwendet und nie ein Array, was auch sinnlos wäre, da ein Dekorierer dann mehrere Objekte gleichzeitig dekorieren würde.
Vieleicht wäre es sogar verständlicher, wenn in dieser UML-Darstellung für die Aggregation zusätzlich Cardinalitäten angegeben wären.
Decorator "enthält" N:1 Komponenten
( was soviel heissen wuerde: 
- ein Decorator kann immer nur eine Komponente enthalten
- eine Komponente kann in mehreren Dekoratoren enthalten sein
)
Gruß
schmofarz
:Ja, du hast Recht. Ich glaube, das ist ein Überbleibsel aus dem GoF-Buch, an dem an dieser Stelle (fälschlicherweise) auch ein Aggregationspfeil eingezeichnet ist. In ihrem Code-Beispiel später schreiben GoF dann auch (S. 181): "Decorator decorates the VisualComponent referenced by the _component instance variable, which is initialized in the constructor", und _component ist ein Zeiger. Das dekorierende Objekt muss das dekorierte kennen, nicht im Bauch haben. Also eine Assoziation. --Wikiplex 16:18, 16. Aug. 2009 (CEST)
replies: text:  Das sehe ich anders. Der Unterschied zwischen Assoziation und Aggregation ist nicht die Multiplizität, sondern die Semantik. Aggregation ist eine Teil-Ganzes-Beziehung. Was auch immer das im jeweils konkreten Fall heißt. Im Code sieht man den Unterschied im Allgemeinen nicht. zumindest nicht direkt. Semantisch übernimmt aber das Ganze eine Stellvertreterrolle für seine Teile. Die Teile lassen sich indirekt über das Ganze "bedienen". Und genau so ist es auch hier. Der Decorator ist Stellvertreter, also gewissermaßen das "Ganze". --Der Hâkawâti ✉ 22:29, 27. Aug. 2009 (CEST)
replies: text:  Ok, überzeugt! Vielleicht sollte man (wir?) mal irgendwo verständlich und mit verständlichen Beispielen den Unterschied zwischen Assoziation, Aggregation und Komposition herausarbeiten. Was ist ein realistisches und einfach zu verstehendes Beispiel für eine Aggregation, die keine Komposition ist? Sag jetzt bitte nicht "der Dekorierer". "Unternehmen besteht aus Abteilungen (die nur durch Auftrag des Unternehmens handeln, von diesem aber nicht existenzabhängig sind)"? :-) Grüße! --Wikiplex 23:39, 27. Aug. 2009 (CEST)
replies: text:  Abteilung passt nicht. Die sind immer existenzabhängig, sonst sind es Subunternehmen oder sowas. Einfachstes Beispiel für Aggregation, die keine Komposition ist: eine (Fußball-)Mannschaft. Wird die Mannschaft aufgelöst, weil die Spieler keine Lust mehr haben, werden sie beshalb noch lange nicht umgebracht. ;-) Die Spieler sind jedoch Teil der Mannschaft, deshalb Aggregation und keine einfache Assoziation. Eine Assoziation besteht hingegen zum Trainer. Der ist wohl nicht Teil der Mannschaft (und existenzabhängig erst recht nicht). Eine Komposition hingegen ist so stark, dass ich bei ner Mannschaft auf die Schnelle gar kein Beispiel finde. Das wäre sowas wie Buch<#>---->Kapitel. Ein Kapitel ist immer Teil eines Buches. Wird das Buch zerstört, ist auch das Kapitel nicht mehr da. daneben gibt es noch Abhängigkeiten(Dependencies). Diese sind noch schwächer als Assoziationen. Technisch sind das z.B. Übergabeparameter an Methoden. --Der Hâkawâti ✉ 20:51, 28. Aug. 2009 (CEST)
replies: text: Schöne Beispiele! Mein "Beispiel" mit dem Unternehmen (das mir ja auch seltsam vorkam) habe ich aus dem sehr bekannten Buch "OO Softwareentwicklung" von Bernd Oesterreich. Dort wird als Beispiel für ein Aggregiertes, das selbst wieder Aggregat ist, genannt: "Unternehmen besteht aus Abteilungen, die aus Mitarbeitern bestehen." Es scheint allgemein selbst unter Fachleuten eine ziemlich Verwirrung zu bestehen... --Wikiplex 09:59, 1. Sep. 2009 (CEST)
thread_title:  Warum wird vom Dekorierer zum obersten Interface immer ein Aggregationspfeil gezeichnet? 

message: Der Text, auf den ich mich beziehe, wurde zwar als Blog-Spam entfernt, aber die Änderungen des Nutzers am Artikel wurden belassen. Also schreibe ich meine Antwort hier als Löschbegründung.
*Man kann darüber diskutieren, aber solang hier nur eine eigene, nicht durch Quellen gestützte Meinung vertreten wird, gehört sie nicht in den Artikel. 
*Dass das Wesentliche an AOP die Integration vom Dekorierer-Muster ist, sehe ich so nicht. In Design pattern implementation in Java and aspectJ von Hannemann und Kiczales stellt man Verbesserungen für 17 von 23 GoF-Patterns fest. Die entsprechende Änderung am AOP-Artikel werde ich daher zurücksetzen.
*Die umgekehrte Behauptung, dass AOP das Dekorierer-Muster implementiert, müsste ebenso begründet werden. Ich frage mich, wie durch AspectJ "meinVerschnupftesVerhustetesMonster" und "meinVerhustetesVerschnupftesMonster" so erstellt werden können, dass die Implementierung des Dekorierers durch AspectJ offensichtlich ist.
--Zahnradzacken 12:38, 5. Mär. 2010 (CET)
thread_title:  Sprachintegration 

message: Python unterstützt ja (da Funktionen „first-class citizens“) sind Dekorierer im Sinne dieses Artikels schon immer; seit Version 2.4 () werden diese für Funktionen bzw. Methoden und seit Version 2.6 auch für Klassen () syntaktisch unterstützt (siehe hier).
Ich sehe das jetzt so, daß es sich bei der neuen Syntax um Annotationen handelt, die die vorher schon vorhandenen Dekorierer syntaktisch unterstützen. Korrekt? --Tobias 17:21, 20. Jan. 2011 (CET)
thread_title:  Python 

message: Im deutschen Artikel steht "Die Instanz eines Dekorierers wird vor die zu dekorierende Klasse geschaltet."
Aber in der englischen Version heißt es "In object-oriented programming, the decorator pattern is a design pattern that allows behavior to be added to an individual object, either statically or dynamically, without affecting the behavior of other objects from the same class."
Was stimmt jetzt? --J.Ammon (Diskussion) 17:53, 31. Jan. 2013 (CET)
replies: text: Objekt stimmt. Klasse macht genau genommen keinen Sinn.Ich vermute mal die Verwechslung rührt da her, dass man umgangssprachlich manchmal Klasse und Objekt nicht sauber trennt. Der ganze Abschnitt ist, sagen wir mal, etwas "umgangssprachlich" und wenig konkret formuliert.--Der Hâkawâti ✉ 20:07, 31. Jan. 2013 (CET)
thread_title:  Dekoriert der Decorator eine Klasse oder ein Objekt?