Das Observer Design Pattern ähnelt einem Podcast

Wenn Sie Podcasts anhören, sind Sie bereits mit dem Observer-Muster vertraut. In der Tat sind Sie ein "Beobachter".

Hier ist die Definition für das Observer-Muster:

Das Observer-Muster definiert eine Eins-zu-Viele-Abhängigkeit zwischen Objekten, sodass alle abhängigen Objekte automatisch benachrichtigt und aktualisiert werden, wenn ein Objekt den Status ändert.

Sehen wir uns die Definition im Zusammenhang mit Podcasts an.

Ich habe einen interessanten Podcast namens Entwicklertee gefunden.

Nachdem ich auf die Schaltfläche ABONNIEREN geklickt habe, bin ich jetzt auf der Abonnentenliste.

Wenn Entwickler-Tee eine neue Episode veröffentlicht, benachrichtigt die App mich und andere Abonnenten. Es lädt die neue Episode für uns herunter.

Das ist genau die Definition des Observer-Musters!

Das Observer-Muster definiert eine Eins-zu-Viele-Abhängigkeit zwischen Objekten, sodass alle abhängigen Objekte automatisch benachrichtigt und aktualisiert werden, wenn ein Objekt den Status ändert.

Zwischen dem Entwickler-Tee-Podcast und den Abonnenten besteht eine Eins-zu-Viele-Beziehung.

Wenn Entwickler-Tee den Status ändert, z. B. wenn eine neue Episode veröffentlicht wird, werden alle Abonnenten des Entwickler-Tees benachrichtigt und aktualisiert.

Lassen Sie es uns in Ruby implementieren.

Beginnen Sie mit einer einfachen Version.

Die Podcast-Klasse enthält eine Liste von Episoden und eine Methode zum Hinzufügen von Folge zu der Liste.

Dann können wir den developer_tea-Podcast erstellen und Episode 1 wie folgt hinzufügen:

Ich möchte benachrichtigt werden, wenn eine neue Episode veröffentlicht wird.

Wir können mich aktualisieren, nachdem wir der Liste eine neue Episode hinzugefügt haben:

Und wenn ich ein Update von developer_tea erhalte, kann ich die neueste Episode herunterladen.

Ich höre mir gerne developer_tea an und empfehle es meiner Freundin Amber. Nun möchte Amber es auch abonnieren.

Wir müssen sicherstellen, dass Amber auch eine Benachrichtigung erhält, wenn eine neue Episode veröffentlicht wird:

Hmmm, dieser Code macht was wir wollen.

Aber es gibt ein Problem.

Jedes Mal, wenn wir einen Abonnenten hinzufügen möchten, müssen wir die Klasse neu definieren.

Gibt es eine Möglichkeit, die Teilnehmerliste zu aktualisieren, ohne die Klasse neu definieren zu müssen?

Wir können eine Abonnentenliste führen!

Die neue Podcast-Klasse führt mithilfe von zwei neuen Methoden eine Abonnentenliste: eine zum Hinzufügen von Abonnenten und eine zum Entfernen von Abonnenten. Wenn eine Episode veröffentlicht wird, aktualisieren wir jeden Abonnenten.

Leider gefällt Amber der Podcast nicht so gut wie mir und beschließt, sich abzumelden. Wir verwenden die Methode remove_subscriber, um sie aus der Abonnentenliste zu entfernen.

Ja! Sie haben gerade das Observer-Muster gelernt!

Konstruktionsprinzip hinter dem Observer-Muster.

Das Observer-Muster basiert auf dem Prinzip des Loose Coupling:

Streben Sie nach locker gekoppelten Designs zwischen Objekten, die interagieren.

Die Podcast-Klasse weiß nicht viel über ihre Abonnenten. Es ist nur bekannt, dass jeder Teilnehmer eine Aktualisierungsmethode hat.

Diese lose Kopplung minimiert die Abhängigkeit zwischen Podcast und seinen Abonnenten. Es maximiert auch die Flexibilität. Solange es eine Aktualisierungsmethode gibt, kann ein Abonnent alles sein: ein Mensch, eine Gruppe von Menschen, ein Tier oder sogar ein Auto.

Imbissbuden:

  1. Das Observer-Muster definiert eine Eins-zu-Viele-Abhängigkeit zwischen Objekten, sodass alle abhängigen Objekte automatisch benachrichtigt und aktualisiert werden, wenn ein Objekt den Status ändert.
  2. Konstruktionsprinzip für lose Kopplungen: Streben Sie nach locker gekoppelten Konstruktionen zwischen Objekten, die interagieren.

Danke fürs Lesen. Gibt es noch andere Beispiele für das Observer-Muster, die Sie sich vorstellen können?

Ich veröffentliche wöchentlich auf sihui.io.

Abonnieren Sie, damit Sie den nächsten Artikel aus der Serie nicht verpassen.

Nächstes Mal reden wir über ...