Diskussion:Besucher (Entwurfsmuster)

message: ein visitor dient mehr oder weniger dazu, double dispatch zu implementieren, wenn die sprache von sich aus nur single dispatch anbietet. -- ∂ 21:31, 12. Jun. 2008 (CEST)
thread_title:  note to self 

message: * Innerhalb des Kontra-Punktes: "Müssen neue konkrete Elemente hinzugefügt werden, so führt dies dazu, dass enorm viele Besucher-NimmEntgegegen-Methoden implementiert werden müssen." - müsste es hier nicht "Besucher-besuche-Methoden" heißen? -- neogrande 11:08, 09. Sep. 2008 (CEST)
thread_title:  Fehler 

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 11:02, 2. Mär. 2009 (CET)
thread_title: Bildbeschreibung fehlt bei ''<nowiki>[[Bild:Besucher.png]]</nowiki>'' 

message: Die Assoziationen im UML sind nicht korrekt, die Implementation eines Interfaces wird m.E. nicht durch eine durchgezogene, sondern durch eine gestrichelte Linie dargestellt. 
Desweiteren würde ich eine klarere Kennzeichnung der Interfaces als solche vorschlagen.
Wiebketru (Diskussion) 17:38, 1. Jun. 2012 (CEST)
thread_title:  UML 

message: Wie beim englischen Artikel diskutiert, ist das Beispiel in einem Punkt seltsam: Meiner Ansicht nach müsste Car ebenfalls von CarElement erben und eine accept-Funktion anbieten, die die accept-Funktionen seiner
elemente aufruft.
Alternativ sollte irgendwo eine Funktion VisitCar(Car c, Visitor v) existieren, die das Aufrufen der einzelnen accept-Funktionen ermöglicht.
Denn die aktuelle Implementierung verletzt das DRY-Prinzip. (nicht signierter Beitrag von 93.190.250.146 (Diskussion | Beiträge) 10:05, 22. Jul 2009 (CEST)
thread_title:  Beispiel falsch oder zumindest verwirrend 

message: Es ist schon im Ansatz richtig, allerdings sollte das Beispiel etwas verändert werden, um die Verwirrung zu beseitigen.
Die Klasse Car repräsentiert kein konkretes Element (CarElement) sondern entspricht der Klasse "Objektstruktur" im UML Diagramm, die eine Liste von CarElementen (also Wheel, Engine oder was auch immer) kennt. 
Diese Klasse ruft bei Bedarf die accept(besucher) methoden für all seine Elemente auf.
        for(CarElement carElement : car.getElements()) {
            carElement.accept(this);
        }
da das car-objekt nicht selbst in der Liste vertreten ist (es ist ja der Einstiegspunkt), braucht es die accept methode auch nicht implementieren! Ausserdem erbt Sie auch nicht von der Schnittstelle CarElement und ist deshalb eh nicht gezwungen, die Methoden des Interfaces (hier ist es nur die accept Methode) zu implementieren. 
Halten wir fest: Die Klasse Car ist von den anderen Klassen wie "Wheel, Engine" etc. abzuheben, da Sie NICHT von der Abstrakten Klasse Element (siehe UML) erbt, sondern der Klasse Objektstruktur enspricht und somit auch NICHT von den Besuchern besucht wird. Sie bietet lediglich den "Wurzelknoten" wenn man so will, der benötigt wird, damit die Traversierung der Struktur durch Besucher angestoßen werden kann. (siehe for-schleife von oben)
Das einzig verwirrende ist, dass die methode
void visitCar(Car car) 
im Visitor Interface definiert worden ist, wo Sie eigentlich nicht hingehört. Weil wie oben erwähnt, die Klasse Car nicht zu der zu Traversierenden Objektstruktur selbst gehört, sondern diese lediglich "kennt" und als Einstiegspunkt fungieren soll.
Es funktioniert natürlich, so wie es im Beispiel gezeigt ist, allerdings würde ich Vorschlagen, die Methode visitCar(Car car) aus dem Interface Visitor zu entfernen, sowie aus den Klassen, die die Schnittstelle implementieren (DoVisitor und PrintVisitor). 
Den Algorithmus, zum Aufrufen der accept methoden (oben genannte for-schleife) sollte dann ganz unten in der Klasse VisitorDemo erfolgen. 
-- Simon Schaper (nicht signierter Beitrag von 80.171.73.23 (Diskussion | Beiträge) 09:34, 12. Aug. 2009 (CEST)
thread_title:  Erklärungsversuch 

message: Welcher Dödel ist auf die Idee gekommen lokale Variablennamen groß zu schreiben? Das ist Javacode und keine Skriptsprache!
Der Javabeispielcode von früher war wesentlich besser, auch von der Formatierung und Semantik. Warum kann hier jeder daherkommen und seinen Mist verbreiten? (nicht signierter Beitrag von 93.200.219.130 (Diskussion) 02:55, 3. Nov. 2012 (CET)
replies: text: Die Antwort auf deine Frage ist einfach: Wiki-Prinzip. --Sebastian.Dietrich  ✉ 18:40, 4. Nov. 2012 (CET)
thread_title:  Was soll der Mist 

message: Wikipedia ist keine Sammlung von Codebeispielen. Wenn schon Code, dann kurz und knackig. Das Beispiel war alles andere als kurz und knackig, darüberhinaus auch noch von den Naming-Conventions etc. her umstritten (siehe Beiträge weiter oben). Wenn dann bitte ein möglichst kurzes Beispiel basierend auf den (allgemein auch befolgten) Java Naming Conventions. --Sebastian.Dietrich  ✉ 18:39, 4. Nov. 2012 (CET)
thread_title:  Beispiel gelöscht 

message: Wenn ich die englische Version dieses Artikels mit der deutschen Version vergleiche, dann wundere ich mich darüber, dass beide das selbe Thema abhandeln sollen.
Aus der deutschen Version geht ein völlig anderes Kernkonzept aus der Beschreibung hervor als es bei der englischen der Fall ist.
Im Übrigen habe ich sogar den Eindruck, dass in der Beschreibung der deutschen Version lediglich eine ganz ordinäre Schichtentrennung beschrieben wird.
Der Kern des Besuchermodells ist nämlich nicht, beliebig viele disjunkte Funktionen auf Objekten auszuführen, sondern dass zwei oder mehr konkrete, aber polymorphe Objekte zur Laufzeit sich gegenseitig ihre aktuellen Laufzeittypen übermitteln (vtable etc.), damit eine konkrete Funktion mit den jeweiligen Laufzeittypen aller Objekte arbeitet. Und eben genau das ist nur notwendig, wenn eine Sprache dies nicht nativ unterstützt.
Aber eben dies geht aus der deutschsprachigen Version dieses Artikels leider nicht hervor.
--My2Cents (Diskussion) 12:19, 14. Jan. 2015 (CET)
replies: text: Danke dass du dich des Artikels annehmen wirst und dies auch bequellt einbauen wirst. --Sebastian.Dietrich  ✉ 20:16, 14. Jan. 2015 (CET)
thread_title:  Thema verfehlt