https://youtube.com/playlist?list=PLJLxLMyDiWkrlV-NuWXWe7t404_fhoDsV
Tag Archives: observer
Beobachtermuster

Das Observer-Muster bezieht sich auf Verhaltensentwurfsmuster.
Das Muster ermöglicht es Ihnen, eine Änderung im Zustand eines Objekts über eine gemeinsame Schnittstelle an Abonnenten zu senden.
Nehmen wir an, wir entwickeln einen Messenger für Programmierer, wir haben einen Chat-Bildschirm in der Anwendung. Wenn Sie eine Nachricht mit dem Text „Problem“ und „Fehler“ oder „etwas stimmt nicht“ erhalten, müssen Sie den Fehlerlistenbildschirm und den Einstellungsbildschirm rot einfärben.
Als Nächstes beschreibe ich zwei Optionen zur Lösung des Problems. Die erste ist einfach, aber äußerst schwierig zu unterstützen, und die zweite ist wesentlich stabiler in der Unterstützung, erfordert aber bei der ersten Implementierung ein Kopfdrehen.
Gemeinsamer Bus
Alle Implementierungen des Musters beinhalten das Senden von Nachrichten bei Datenänderungen, das Abonnieren von Nachrichten und die weitere Verarbeitung in Methoden. Die Shared-Bus-Option enthält ein einzelnes Objekt (normalerweise ein Singleton), das Nachrichten an Empfänger versendet.
Die Einfachheit der Implementierung ist wie folgt:
- Das Objekt sendet eine abstrakte Nachricht an den gemeinsam genutzten Bus
- Ein anderes Objekt, das den gemeinsam genutzten Bus abonniert hat, fängt die Nachricht ab und entscheidet, ob sie verarbeitet wird oder nicht.
Eine der von Apple verfügbaren Implementierungsoptionen (NSNotificationCenter-Subsystem) fügte den Abgleich des Nachrichtenheaders mit dem Namen der Methode hinzu, die vom Empfänger bei der Zustellung aufgerufen wird.
Der größte Nachteil dieses Ansatzes – Wenn Sie die Nachricht weiter ändern, müssen Sie sich zunächst alle Orte merken und dann manuell bearbeiten, an denen sie verarbeitet und gesendet wird. Es handelt sich um eine schnelle Erstimplementierung, gefolgt von einem langen, komplexen Support, der eine Wissensbasis für den korrekten Betrieb erfordert.
Multicast-Delegierter
In dieser Implementierung erstellen wir die endgültige Multicast-Delegatenklasse; genau wie im Fall eines gemeinsam genutzten Busses können Objekte diese abonnieren, um „Nachrichten“ oder „Ereignisse“ zu empfangen, die Arbeit des Parsens und Filterns von Nachrichten ist jedoch anders nicht den Objekten zugeordnet. Stattdessen müssen Abonnentenklassen die Multicast-Methoden des Delegaten implementieren, mit denen er sie benachrichtigt.
Dies wird durch die Verwendung von Delegate-Schnittstellen/-Protokollen implementiert. Wenn sich die allgemeine Schnittstelle ändert, wird die Anwendung nicht mehr erstellt. Zu diesem Zeitpunkt müssen alle Stellen für die Verarbeitung einer bestimmten Nachricht neu erstellt werden, ohne dass eine separate Wissensdatenbank verwaltet werden muss um mich an diese Orte zu erinnern. Der Compiler ist dein Freund.
Dieser Ansatz erhöht die Produktivität des Teams, da keine Dokumentation geschrieben oder gespeichert werden muss und ein neuer Entwickler nicht versuchen muss, zu verstehen, wie eine Nachricht und ihre Argumente verarbeitet werden, sondern sie mit einer praktischen und verständlichen Benutzeroberfläche arbeiten , so wird das Dokumentationsparadigma durch Code umgesetzt.
Der Multicast-Delegat selbst basiert auf dem Delegatenmuster, über das ich im nächsten Beitrag schreiben werde.
Quellen
https://refactoring.gu/ru/design-patterns/observer