Diskussion:Decorator

Aufrufer sieht Dekorierer nicht?

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)

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)

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)

Broadcast-Mechanismus

"Manchmal behilft man sich mit einem Broadcast-Mechanismus". Was soll das heißen? Ich verstehe diese Aussage nicht und würde sie daher gerne herausnehmen. Wikiplex 12:54, 17. Nov. 2006 (CET)

Sehe ich auch so.--Kilessan 17:51, 29. Sep. 2007 (CEST)

Schließe mich der Meinung an, das wirft an der Stelle mehr Fragen als Antworten auf. Raus damit! Schorsch

Ich habe jetzt, nachdem lange nichts mehr dazu gesagt worden ist, die aufgezählten "Nachteile" herausgenommen, weil sie mir als Nachteile nicht einleuchtend sind oder schlichtweg verwirrend. Ich habe stattdessen eine Gefahr aufgenommen, die auch so im GoF-Patterns-Buch genannt wird. --Wikiplex 16:50, 16. Aug. 2009 (CEST)

Warum englisch?

Warum trägt der Artikel hier eigentlich den englischen Namen und nicht Dekorierer?? Benutzer:Micha_koller

Bin auch für "Dekorierer-Muster". Es heißt ja auch "Schablonen-Muster", "Strategie-Muster", "Abstrakte Fabrik" usw. --Wikiplex 18:32, 18. Aug. 2009 (CEST)

Bitte nicht mit Bindestrich; wenn ein Suffix nötig ist, dann bitte „ (Entwurfsmuster)“, in Analogie zu Singleton (Entwurfsmuster), Prototyp (Entwurfsmuster) usw.

Übrigens hat es einmal einen Artikel Dekorator gegeben, der 2007 als "überflüssige Umleitung" gelöscht wurde; ich weiß nicht, ob der mit unserem Thema in Verbindung stand. --Tobias 17:21, 20. Jan. 2011 (CET)

Ich bin klar für Dekorierer oder Dekorierer (Entwurfsmuster), schließlich ist das die Übersetzung aus dem GoF-Buch. Dort steht übrigens irgendwo auch "Dekorierermuster". Auf den Bindestrich darf man also auch in der Form verzichten. --Zahnradzacken 10:44, 29. Dez. 2011 (CET)

Bildbeschreibung fehlt bei [[Bild:Dekorierer.png]]

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 [[Bild:Dekorierer.png]] 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)

Warum wird vom Dekorierer zum obersten Interface immer ein Aggregationspfeil gezeichnet?

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)

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)

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)

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)

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)

Sprachintegration

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)

Python

Python unterstützt ja (da Funktionen „first-class citizens“) sind Dekorierer im Sinne dieses Artikels schon immer; seit Version 2.4 ([1]) werden diese für Funktionen bzw. Methoden und seit Version 2.6 auch für Klassen ([2]) 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)

3 Kopien

Kann mir jemand sagen, wozu drei Kopien des Codes für das "Abenteuerspiel"-Beispiel gut sein sollen, wobei die tatsächlich verwendeten Feature-Sets der Programmiersprachen praktisch identisch sind? --Daniel5Ko 02:00, 30. Dez. 2011 (CET)

Andere Programmiersprachen müssen nicht diskriminierend sein. Wikipedia ist offen, zugänglich und nicht diskriminierend. Identisch Beispielen sind sehr einfach zu verstehen, wenn jemand verfüge über Kenntnisse von mehrere Programmiersprachen. --Ruslan4RT 15:58, 7. Jan. 2012 (CEST)

Das Argument kann ich sprachlich schwer und inhaltlich gar nicht zu verstehen. Willst du sagen, dass zweimal das gleiche Beispiele eine Idee besser vermittelt?

Wenn ich also eine Idee erklären will, dann schreibe ich sie einfach zweimal auf? Wenn ich also "Addition" erklären will, dann sage ich:

• Zum Beispiel hat in Java der Ausdruck 2.0 + 2.0; den Wert 4.0
• Zum Beispiel hat in C++ der Ausdruck 2+2; den Wert 4

Finde ich nicht sinnvoll. Durch ein zweites Beispiel lernt man weder etwas über die andere Sprache, noch über die Addition. --Zahnradzacken 16:41, 7. Jan. 2012 (CET)

Nein. Ich will sagen, dass identische Beispiele sind sehr einfach zu verstehen, wenn jemand verfüge über Kenntnisse von mehrere Programmiersprachen. Ich habe gesagt was ich gesagt. Es ist relativ zum Programmierung. Ob du las "Entwurfsmuster. Elemente wiederverwendbarer objektorientierter Software", dann kannst du erinnern, dass die Beispiele sind ähnlich. Findest du diese auch nicht sinnvoll? Ja?

• Ich denke auch dass identische Beispielen geben eine Möglichkeit schnell andere Sprachen zu lernen, man kann die Beispiele vergleichen und Unterschied zu verstehen.
• Identische Beispielen geben eine Möglichkeit schnell die Artikel zu lesen. Man braucht weniger Zeit für Untersuchung der Beispielen.
• Ihres Argument ist nicht sinnvoll. 2+2 ist es nicht Entwurfsmuster. Es ist verschiedene Sachen. Du spricht über Idee, aber ich spreche über verschiedene Programmiersprachen und Nutzung von Entwurfsmuster in verschiedene Programmiersprachen. --Ruslan4RT 23:40, 7. Jan. 2012 (CEST)

Wenn du mein Beispiel nicht als Metapher verstehen kannst, ahne ich schon besser, warum du gerne identische Beispiele hast.

Du sprichst jetzt also von "verschiedenen Programmiersprachen". Wenn bei den Code-Beispielen aber die Unterschiede zwischen den Programmiersprachen kaum sichtbar sind, dann findest du das gut, weil man dann nur ein Beispiel lesen muss? Du erwähnst das Buch "Entwurfsmuster" und dass darin ähnliche Beispiele sind. Wo denn bitte? Decorator wird nur mit einer Programmiersprache erklärt.

Sinnvoll fände ich zwei Varianten:

• In einer Sprache werden zwei ähnliche, aber verschiedene Beispiele gezeigt (2+2 und -1 + 3)
• Ein und dasselbe Beispiel wird in deutlich unterscheidbaren Sprachen gezeigt (2+2 und (+ 2 2))

--Zahnradzacken 23:50, 7. Jan. 2012 (CET)

"Entwurfsmuster. Elemente wiederverwendbarer objektorientierter Software" - z. B. Seite 117, Abstrakte Fabrik, Beispiel an Smalltalk. Findest du diese auch nicht sinnvoll?

Nein. Ich finde nicht gut, wenn man nur ein Beispiel lesen muss. Beispiele sind Nutzung (oder Verwendung) von Entwurfsmuster in verschiedenen Programmiersprachen.

Man kann über Entwurfmuster ohne Beispielen erlernen. UML ist allgemeingültig Vermittlung von Ideen. --Ruslan4RT 11:17, 8. Jan. 2012 (CEST)

Ich verstehe dein Beispiel als Metapher sehr gut. Wir sprechen über verschiedenen Sachen. Du - über Vermittlung von Ideen, ich - über Nutzung (oder Verwendung) von Entwurfsmuster in verschiedenen Programmiersprachen. Ich habe verstanden, dass du über Ideen nur von Beispielen erlernt. --Ruslan4RT 11:46, 8. Jan. 2012 (CEST)

Ja, Vermittlung von Ideen stehen hier im Vordergrund. Für ein How-to gibt es Wikibooks. Siehe auch WP:WWNI. Ich hätte nichts gegen die Gegenüberstellung von C++ und Smalltalk. Aber wenn man C++/C#/Java gegenüberstellt und der Code nahezu identisch ist, dann bläht das den Artikel vor allem auf. --Zahnradzacken 13:29, 8. Jan. 2012 (CET)

Ja, einverstanden mit Aufblähung der Artikel. Aber jemand muss nicht diskriminieren oder propagandieren konkreten Programmiersprachen.

Ich denke, dass:

• Wenn jemand nur einer Beispiel an einer Programmiersprache lässt, dann jener diskriminiert andere Programmiersprachen und propagandiert diese Sprache.
• Wenn alle Beispiele gegeben sind, dann alles ist gut.
• Wenn kein Beispiel gegeben ist, dann alles ist gut.

Vielleicht, wäre am besten alle Programmierbeispiele entfernen und nur allgemeingültige Vermittlung von Idee mit UML lassen?

--Ruslan4RT 16:40, 8. Jan. 2012 (CEST)

Ausschließlich UML ist vielleicht deswegen schlecht, weil zum Beispiel Blinde UML nicht gut lesen können - das ist jedoch reine Spekulation. Etwas textbasiertes wäre aus diesem Grund, wenn er denn zutrifft, durchaus sinnvoll.

Und im Gegensatz zu Pseudo-Code hat man mit einer richtigen Programmiersprache wenigstens auch eine definierte Semantik. Welche konkrete Sprache das ist, ist mir persönlich eigentlich egal. Mit Propaganda oder Diskriminierung hat es nichts zu tun, wenn ich "3 Kopien" moniere. --Daniel5Ko 03:06, 12. Jan. 2012 (CET)

Ich mache mal eine Analogie auf: Wenn jemand einen Artikel als Hauptautor verfasst hat, dann ist sein persönlicher Schreibstil da eingeflossen. Man kann den Stil auch ändern, aber es gilt als schlechtes Benehmen, wenn jemand kommt und den Stil des Artikels ändert, ohne an Inhalt, Gliederung o. ä. irgendwas zu ändern. Dementsprechend gilt in der englischen Wikipedia: wenn jemand einen Artikel z. B. zu einem Alltagsgegenstand in britischem Englisch verfasst, dann ist es inakzeptabel, wenn jemand den Artikel auf amerikanisches Englisch umstellt, ohne ihn auch inhaltlich in wesentlichen Teilen neu zu schreiben. Es gibt also eine allgemeine Konvention, bei mehreren korrekten Alternativen die Alternative zu belassen, die der ursprüngliche Autor gewählt hat. Da C# dies zu sein scheint[3], werde ich die anderen Alternativen entfernen. --dealerofsalvation 20:02, 17. Jan. 2012 (CET)

@Ruslan4RT: Du hast deine Meinung kundgetan, sie wird nicht geteilt. Deine Ansicht über Diskriminierung und Propaganda ist an den Haaren herbei gezogen. Ein Beispiel zur Veranschaulichung ist sinnvoll, dreimal das gleiche Beispiel ist nicht sinnvoll. Hier geht es um ein Pattern, nicht um Programmiersprachen. Lass das Löschen nützlicher Beispiele bitte bleiben. --Zahnradzacken 12:49, 18. Jan. 2012 (CET)

@Zahnradzacken Entfernung von anderen Bespiele ist Diskriminierung von anderen Programmiersprachen. Es ist Machtmissbrauch von Sichter. Vielleicht wollen Sie in diese Artikel Singleton andere Beispiele entfernen? Los! --Ruslan4RT 15:22, 18. Jan. 2012 (CEST)

Über den Singleton-Artikel mag man gerne unter Diskussion:Singleton (Entwurfsmuster) diskutieren. Aber auch wenn vieles für einheitliche Handhabung in Artikeln über Patterns spricht, wären die Ergebnisse nicht unbedingt übertragbar auf diesen Artikel, weil die Code-Beispiele im Singleton-Artikel sehr viel kürzer sind. Vielleicht mag jemand unter Wikipedia Diskussion:Redaktion Informatik oder PD:Informatik eine Anfrage anleiern? --dealerofsalvation 07:26, 25. Jan. 2012 (CET)

Dekoriert der Decorator eine Klasse oder ein Objekt?

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)

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)