Diskussion:Beobachter (Entwurfsmuster)

Implementierungen jetzt bei wiki-books

Leider wurden die Implementierungen in den verschiedenen Sprachen nur gelöscht. Ich habe nun aus er vorhergehenden Version die Implementierungen nach wiki-books übertragen. Es wäre Schade, wenn das verloren geht.

• Python
• PHP5
• JavaScript

--Cebel 13:12, 22. Mär. 2010 (CET)

Irgendwas

Ich habe das ganze an die Struktur der anderen Muster angepasst. Der Abschnitt über Listener und Events in Java müsste allerdings ergänzt werden. Inwiefern werden die Nachteile durch diese Lösung vermieden? Wie sieht ihre Verwendung aus? --guwac 14:21, 7. Mär 2005 (CET)

UML-Diagramm: Subjekt

Sollte man im UML-Diagramm und im Abschnitt Akteure die abstrakte Klasse Subjekt nicht lieber Beobachtbares Subjekt nennen? --Head 20:45, 18. Aug 2005 (CEST)

Der Begriff Subjekt hat sich als Begriff im Beobachter Entwurfsmuster eingebürgert. Ich bin gegen die Umbenennung, außerdem steht hinter dem Subjekt in Klammern beobachtbares Subjekt. --Moewe 09:04, 19. Aug 2005 (CEST)

Fehlt im Diagramm nicht das konkrete Subjekt?(nicht signierter Beitrag von 212.184.117.166 (Diskussion) 10:57, 13. Mai 2008)

Ja, das fehlt...--Thomaserl 16:32, 23. Feb. 2009 (CET)

Java Implementation

Die Java Implementierung bezog sich nur auf eine Schnittstelle. Der Erkenntnisgewinn ist gering, weil die selben Informationen bereits im UML erkennbar sind. Desweiteren erklärt das UML-Diagram auch, welche Aufgaben die Klassen und deren Methoden haben. --Moewe 09:20, 19. Aug 2005 (CEST)

Publish-Subscribe

Was ist der Unterschied zum Publish-Subscribe-Modell? -- Nichtich 02:12, 17. Jan 2006 (CET)

Zitat aus dem Buch der Gang of Four: „This kind of interaction is also known as publish-subscribe. The subject is the publisher of notifications.“ (Seite 394 in der englischen Originalausgabe) Publish-Subscribe ist also schlicht ein anderer (älterer) Name für das gleiche Muster. --jpp ?! 12:32, 17. Jan 2006 (CET)

Das Publish-Subscribe-Pattern kann nach meinem Verständnis noch mehr, insbesondere das Filtern der Nachrichten und der optionale Broker machen Pub/Sub zu einem universelleren Pattern. In der englischen Wikipedie steht auch: The observer pattern (a subset of the publish/subscribe pattern) (Observer pattern). Außerdem benutzt man Observer eher innerhalb einer Anwendung, Pub/Sub als Middleware zwischen verschiedenen Anwendungen. Kann sein, dass es vom eigentlichen Wortsinn keinen Unterschied gibt, im alltäglichen Gebrauch aber schon. -- PapaNappa 20:44, 5. Sep. 2010 (CEST)

Das kommt wohl auf den Standpunkt drauf an. GoF sehen beide Begriffe als synonym an. POSA ebenfalls. Ich sehe das so: Die grundlegende Idee ist die selbe. Und die Idee lässt sich sowohl auf Design- als auch auf Architekturebene einsetzen. (Im Übrigen gilt das auch für andere Patterns.) Mein Eindruck ist, dass Publish-Subscribe als Bezeichnung eher für das Architekturmuster und Observer eher für das Entwurfsmuster verwendet wird. Dahingehend stimme ich mit dir überein. Dass das Muster, wenn auf Architekturebene angewendet, oft mit Brokern und Filtern kombiniert wird, halte ich allerdings nicht für eine inhärente Eigenschaft von Publish-Subscribe, sondern eher für eine Variante des Musters. --Der Hâkawâti ✉ 18:29, 6. Sep. 2010 (CEST)

UML-Diagramm: Multiplizitäten

Die Multiplizitäten an den Assoziationen fehlen, oder nicht? Ich kenne das Entwurfsmuster so, dass das Subjekt die Multiplizität 1 und der Beobachter * hat. -- 85.180.77.252 01:46, 4. Mär. 2008 (CET)

Ich habe ein passendes Bild im Wikibook gefunden. Passt das besser? --j ?! 12:14, 5. Mär. 2008 (CET)

Jep. Ist zwar auch nicht ganz so, wie ich das kenne (Subjekt abstrakt und vom konkreten Subjekt getrennt), aber es ist definitiv besser. -- 85.180.64.110 15:26, 1. Mai 2008 (CEST)

Listener und Events bei Java

Mit diesem Abschnitt bin ich absolut nicht einverstanden:

Die Nachteile des Entwurfsmusters entfernt Java, indem es das Beobachterkonzept durch Listener und Events ersetzt. Interessiert sich eine Klasse für eine andere, implementiert sie deren Listener-Interface und meldet sich beim Subjekt an. Ändert sich das Subjekt, informiert es seine Beobachter durch den Aufruf der Listenerschnittstelle, die die Änderung beschreibt.

Was ist denn am Java Event-Handling anders? Der Listener ist der Beobachter, die Klasse, die den Listener implementiert ist der Konkrete Beobachter und der Event-Auslöser ist das Subjekt, bei dem der Konkrete Beobachter registriert wird. Entsprechend gelten alle angeführten Nachteile auch für das Java-Eventhandling. --Trugbild 13:26, 11. Apr. 2008 (CEST)

Bildbeschreibung fehlt bei [[Bild:Beobachter-pattern.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:Beobachter-pattern.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 00:12, 2. Mär. 2009 (CET)

Lemma: Observer in Beobachter ändern

Viele anderen Entwurfsmuster haben den deutschen Begriff als Lemma. Ich denke auch hier sollte man das Lemma von "Observer (Entwurfsmuster)" in "Beobachter (Entwurfsmuster)" ändern. (Oder alle anderen ins Englische umwandeln. Es soll halt einheitlich sein). --Martin Thoma 17:46, 17. Jun. 2012 (CEST)

Es ist ein Monat vergangen, niemand äußert sich, also mach ich es mal einfach. --Martin Thoma 16:58, 17. Jul. 2012 (CEST)

Unverständlich

Allgemein finden Beobachter-Muster Anwendung, wenn eine Abstraktion mehrere Aspekte hat, die von einem anderen Aspekt derselben Abstraktion abhängen, die Änderung eines Objekts Änderungen an anderen Objekten nach sich zieht oder ein Objekt andere Objekte benachrichtigen soll, ohne diese im Detail zu kennen.

Geht's noch? Wenn ich das Beobachter-Muster schon kenne, brauche ich diesen Artikel nicht. Wenn ich davon gehört habe und mich hier näher informieren will, schreckt mich dieses Geschwurbel ab. Liebe Informatikstudenten: Wenn man klar denkt, kann man sich auch klar ausdrücken und muss mit solchem Geschwafel nicht den Anschein erwecken, man hätte es unheimlich drauf. --Rat (Diskussion) 00:24, 29. Dez. 2013 (CET)

Schön dass du dich dessen annehmen & den Artikel entschrubeln wirst. --Sebastian.Dietrich ✉ 02:18, 29. Dez. 2013 (CET)

So schlimm ist der Satz doch gar nicht, auch wenn ich als Informatiker ihn auch erstmal zwei drei mal lesen musste um zu verstehen, was man von mir will. Den ersten Teilsatz könnte man vielleicht noch verständlicher formulieren, der Rest ist aber doch eigentlich schnell verstanden. Vielleicht wäre eine generelle anschauliche Aufzählung gar nicht so schlecht. Da wirken die Sätze selbst unbearbeitet gleich viel verständlicher :) --Petrucciation (Diskussion) 20:51, 10. Okt. 2016 (CEST)

Beispiel in C++

Das Beispiel zeigt zwar das Observer-Pattern auf, hat aber auch so einige Unschönheiten und sogar Fehler, die man sich vielleicht mal zur Brust nehmen sollte.

1. Die Registrierungsmethoden im AbstrSubjekt sollten alle die shared pointer als const references erhalten. Selbst in einem Multithreaded Kontext ist das im Allgemeinen richtig, bzw. muss ein solcher sowieso separat auf ganz anderem Wege solide behandelt werden.
2. Es kann unendlich oft derselbe Observer registriert werden, aber zu einem Zeitpunkt immer nur einer aus dem Vektor wieder gelöscht werden. Das ist sicher nicht im Sinne des Autors gewesen. Hier wäre aus meiner Sicht zumindest bei der gezeigten Funktionalität ein std::set als Basiscontainer eher angebracht, womit man auch gleich das Problem der Registrierung/Deregistrierung gelöst hätte.
3. Der Vollständigkeit halber sollten alle abstrakten Klassen einen virtuellen Destruktor erhalten (= default). Bei lediglicher Nutzung von sharedPtrs führt das Weglassen dieser allerdings auch nicht zu leaks oder anderen Problemen, es ist aber mit diesen einfach empfohlener besserer Stil.
4. In der main()-Funktion werden die sharedPtrs (deren Inhalt) mittels new () ... initialisiert. Es wird empfohlen, nur noch std::make_shared<T>() zu nutzen und nur auf das alte Allokierungsmuster zurückzugreifen, wenn es gar nicht anders geht (weil der Konstruktor protected/private ist z.B.). Grund ist neben der Effizienz vorallem die Exception-Sicherheit.
5. Die casts mittels std::static_pointer_cast() ... in der main()-Funktion sind unschön. Man könnte die Beobachterobjekte besser gleich mittels auto beobachter = std::make_shared<T> (...) initialisieren und man spart sich die casts.
6. In den abgeleiteten konkreten Beobachterklassen fehlen überall die virtual und override - Schlüsselwörter. Ich hoffe inständig, dass der Standard gerade auch hier langsam mal in eine konsistentere Form übergeht und die wenigen Punkte, bei denen eine solche Schlüsselwortpflicht wirklich noch zu anderem Verhalten als dem erwarteten führen würde, zur Not mit einem neuen Schlüsselwort abdeckt.

Mir ist klar, dass es in erster Linie um das Veranschaulichen geht, aber zusätzliche Verwirrung sollte man ja beim Leser und besonders beim Laien ja auch nicht verursachen. Wenn sich dem keiner annehmen sollte, editiere ich den Abschnitt zeitnah entsprechend.

--Petrucciation (Diskussion) 00:51, 10. Okt. 2016 (CEST)

benachrichtigen(b:Beobachter):void

Moin

In der Abbildung zum Abschnitt UML-Diagramm steht

+benachrichtigen(b:Beobachter):void

Das ist doch so nicht richtig, oder? Der Witz ist ja, dass alle registrierten Abonnenten aktualisiert werden, und eben nicht nur einige spezielle. Nach (zugegeben) kurzer Recherche fand ich diese Methode nur ohne Parameter. Oder übersehe ich da was? --St. Magnus (Diskussion) 07:33, 1. Sep. 2023 (CEST)