Observer

Code in:JavaC#PythonJavaScript

Kurz gesagt: Observer lässt ein Objekt eine Liste von Abonnenten benachrichtigen, wenn etwas passiert, ohne zu wissen, wer sie sind und was sie tun.

Problem

Die Zahlung, die alle anruft

Ein Kunde bezahlt die Bestellung #1042 über 80 €. Danach muss ein Beleg per E-Mail und SMS rausgehen, das Lager muss die Ware reservieren, und die Buchhaltung muss eine Rechnung ausstellen. Die Klasse für die Zahlungen macht das alles selbst:

class Payments:
    def __init__(self):
        self.email = EmailService()
        self.sms = SmsService()
        self.warehouse = Warehouse()
        self.invoices = InvoiceService()

    def mark_paid(self, order):
        self.email.send_receipt(order)
        self.sms.notify_paid(order)
        self.warehouse.reserve(order)
        self.invoices.issue(order)

Jeder Dienst ist eine kleine Klasse, die ausgibt, was sie getan hat:

payments = Payments()
payments.mark_paid(Order(1042, 80))

Ausgabe

E-Mail: Beleg für #1042
SMS: Bestellung #1042 ist bezahlt
Lager: reserviere #1042
Rechnung: 80.00 € für #1042

Das funktioniert. Aber das Marketing will Treuepunkte bei jeder Zahlung. Das ist ein Feld mehr und eine Zeile mehr in mark_paid. Morgen kommt eine Push-Benachrichtigung, übermorgen eine Statistik. Der Code, den jede Zahlung durchläuft, wird für Dinge angefasst, die mit der Zahlung nichts zu tun haben.

Schlimmer noch: Heute antwortet das SMS-Gateway nicht:

class SmsService:
    def notify_paid(self, order):
        raise ConnectionError("Das SMS-Gateway antwortet nicht")

payments = Payments()
try:
    payments.mark_paid(Order(1042, 80))
except ConnectionError as e:
    print(f"Zahlung fehlgeschlagen: {e}")

Ausgabe

E-Mail: Beleg für #1042
Zahlung fehlgeschlagen: Das SMS-Gateway antwortet nicht

Das Geld ist abgebucht, und die Seite sagt dem Kunden, die Zahlung sei fehlgeschlagen. Das Lager hat nichts reserviert, es gibt keine Rechnung. Ein Dienst, den niemand für wichtig hält, hat die ganze Zahlung gestoppt.

Die Idee

Observer: Wer es wissen will, abonniert

Die Zahlungen sollen nicht wissen, wen sie interessieren. Sie sollen nur wissen, dass jemand erfahren will, wann eine Bestellung bezahlt ist.

Also führen die Zahlungen eine Liste von Abonnenten. Jeder Abonnent hat dieselbe Form: eine Funktion, die die Bestellung nimmt. Wer es wissen will, meldet sich von außen an. Bei einer Zahlung geht das Objekt die Liste durch und ruft jeden Abonnenten mit der Bestellung auf.

Das ist das Observer-Muster. Es hat drei Rollen:

• das Subjekt ist dort, wo etwas passiert. Hier sind es die Zahlungen. In Büchern heißt es auch Publisher;
• die Abonnenten (Observer) wollen es erfahren. Das sind E-Mail, SMS, das Lager;
• die Benachrichtigung ist der Gang durch die Liste: Jeder Abonnent bekommt, was passiert ist, hier die bezahlte Bestellung.

Ein neuer Abonnent ist neuer Code außerhalb. Das Subjekt wird nicht angefasst. Ein Abonnent kann sich auch abmelden, und dann hört er nichts mehr.

Sieh es dir an

Die Abonnenten erfahren es von selbst

Die Zahlungen halten eine Liste von Funktionen:

from dataclasses import dataclass


@dataclass(frozen=True)
class Order:
    id: int
    total: float


class Payments:
    def __init__(self):
        self._listeners = []

    def subscribe(self, listener):
        self._listeners.append(listener)

    def unsubscribe(self, listener):
        self._listeners.remove(listener)

    def mark_paid(self, order):
        for listener in self._listeners:
            listener(order)

Jeder Abonnent ist eine gewöhnliche Funktion, die die Bestellung nimmt:

def email(order):
    print(f"E-Mail: Beleg für #{order.id}")


def sms(order):
    print(f"SMS: Bestellung #{order.id} ist bezahlt")


def warehouse(order):
    print(f"Lager: reserviere #{order.id}")


def loyalty(order):
    print(f"Punkte: +{int(order.total)} für #{order.id}")

Drei Abonnenten, eine Zahlung. Dann kommen die Treuepunkte, und der Kunde schaltet die SMS ab:

payments = Payments()
payments.subscribe(email)
payments.subscribe(sms)
payments.subscribe(warehouse)
payments.mark_paid(Order(1042, 80))

payments.subscribe(loyalty)
payments.unsubscribe(sms)
payments.mark_paid(Order(1043, 25))

Ausgabe

E-Mail: Beleg für #1042
SMS: Bestellung #1042 ist bezahlt
Lager: reserviere #1042
E-Mail: Beleg für #1043
Lager: reserviere #1043
Punkte: +25 für #1043

payments = Payments()
payments.subscribe(email)
payments.subscribe(sms)
payments.subscribe(warehouse)
payments.mark_paid(Order(1042, 80))

payments.subscribe(loyalty)
payments.unsubscribe(sms)
payments.mark_paid(Order(1043, 25))

Schritt für Schritt, in Worten

1. Payments beginnt mit einer leeren Liste _listeners.
2. email abonniert: Es kommt in die Liste _listeners.
3. sms und warehouse auch. Payments weiß nicht, wer sie sind, nur dass sie eine Bestellung annehmen.
4. Bestellung #1042 ist bezahlt. Die Benachrichtigung geht an jeden Abonnenten, in der Reihenfolge der Anmeldung.
5. Einer nach dem anderen, im selben Aufruf: Beleg, SMS, Reservierung. Jeder Abonnent macht seine Arbeit.
6. Die Treuepunkte kommen: loyalty abonniert von außen. In Payments ändert sich keine einzige Zeile.
7. Der Kunde schaltet die SMS ab: sms meldet sich ab und verlässt die Liste.
8. Bestellung #1043: Die Benachrichtigung erreicht email, warehouse und loyalty. sms steht nicht mehr auf der Liste und erfährt nichts.

Payments ist von Anfang bis Ende derselbe Code. Die Punkte sind aufgetaucht, ohne dass sich eine einzige Zeile geändert hat, und die SMS hat aufgehört, ohne dass die Zahlungen es bemerkt haben.

Genauer, für Neugierige

• Ein Abonnent kann alles sein, was sich aufrufen lässt: eine Funktion, ein Lambda, eine Methode eines Objekts. payments.subscribe(mailer.send_receipt) meldet die Methode eines bestimmten Objekts an. Zweimal geschrieben, ergibt mailer.send_receipt gleiche Werte, also findet unsubscribe(mailer.send_receipt) sie und entfernt sie. Die Zahlung danach gibt nichts aus:

payments = Payments()
mailer = EmailService()
payments.subscribe(mailer.send_receipt)
payments.unsubscribe(mailer.send_receipt)
payments.mark_paid(Order(1042, 80))

• Python hat kein eingebautes Observer. Eine Liste von Funktionen ist der übliche Weg. Der Name _listeners mit Unterstrich sagt „von außen nicht anfassen, benutze subscribe“.
• Die Abonnenten werden nacheinander im selben Aufruf von mark_paid aufgerufen. Ein langsames SMS-Gateway bremst auch die Zahlung. Große Shops schicken das Ereignis an eine Warteschlange (einen Message Broker), und die Dienste holen es dort ab, wenn sie bereit sind.

Sieh es dir an

Ein Abonnent scheitert, die anderen nicht

Observer hat die Verbindung zwischen der Zahlung und der SMS entfernt, aber nicht den Fehler. Der SMS-Abonnent wirft:

def sms(order):
    raise ConnectionError("Das SMS-Gateway antwortet nicht")

payments = Payments()
payments.subscribe(email)
payments.subscribe(sms)
payments.subscribe(warehouse)
try:
    payments.mark_paid(Order(1042, 80))
except ConnectionError as e:
    print(f"Zahlung fehlgeschlagen: {e}")

Ausgabe

E-Mail: Beleg für #1042
Zahlung fehlgeschlagen: Das SMS-Gateway antwortet nicht

Die Abonnenten werden in einer Schleife aufgerufen, und die Exception der SMS verlässt die Schleife. Das Lager reserviert weiter nichts, und der Fehler erreicht weiter die Zahlung. Das Subjekt muss jeden Aufruf einzeln schützen:

def mark_paid(self, order):
    for listener in self._listeners:
        try:
            listener(order)
        except Exception as e:
            print(f"Ein Abonnent ist fehlgeschlagen: {e}")

Mit demselben Programm:

payments = Payments()
payments.subscribe(email)
payments.subscribe(sms)
payments.subscribe(warehouse)
try:
    payments.mark_paid(Order(1042, 80))
except ConnectionError as e:
    print(f"Zahlung fehlgeschlagen: {e}")

Ausgabe

E-Mail: Beleg für #1042
Ein Abonnent ist fehlgeschlagen: Das SMS-Gateway antwortet nicht
Lager: reserviere #1042

Die Zahlung ging durch, das Lager hat reserviert, und der Fehler ist festgehalten. In einem echten Shop geht diese Zeile ins Log, und die SMS wird später erneut versucht.

Probier es aus

Was kommt heraus?

Die Abonnenten sind die aus der Karte „Die Abonnenten erfahren es von selbst“. Was gibt das Programm aus?

payments = Payments()
payments.subscribe(email)
payments.subscribe(warehouse)
payments.subscribe(email)
payments.mark_paid(Order(7, 10))

payments.unsubscribe(warehouse)
payments.mark_paid(Order(8, 10))

Antwort

E-Mail: Beleg für #7
Lager: reserviere #7
E-Mail: Beleg für #8

E-Mail: Beleg für #7
E-Mail: Beleg für #7
Lager: reserviere #7
E-Mail: Beleg für #8
E-Mail: Beleg für #8

E-Mail: Beleg für #7
Lager: reserviere #7
E-Mail: Beleg für #7
E-Mail: Beleg für #8
E-Mail: Beleg für #8

Prüfen

Probier es aus

Finde den Fehler

Den Willkommensgutschein gibt es nur für die erste bezahlte Bestellung. Der Gutschein-Abonnent meldet sich also selbst ab, sobald er ihn gesendet hat:

def welcome_coupon(order):
    print(f"Willkommensgutschein: #{order.id}")
    payments.unsubscribe(welcome_coupon)

payments = Payments()
payments.subscribe(welcome_coupon)
payments.subscribe(email)
payments.subscribe(warehouse)
payments.mark_paid(Order(1042, 80))
payments.mark_paid(Order(1043, 25))

Ausgabe

Willkommensgutschein: #1042
Lager: reserviere #1042
E-Mail: Beleg für #1043
Lager: reserviere #1043

Die Bestellung #1042 hat keinen Beleg per E-Mail bekommen. In welcher Zeile von Payments steckt der Fehler?

Wähle die Zeile mit dem Fehler.

1class Payments:2 def __init__(self):3 self._listeners = []45 def subscribe(self, listener):6 self._listeners.append(listener)78 def unsubscribe(self, listener):9 self._listeners.remove(listener)1011 def mark_paid(self, order):12 for listener in self._listeners:13 listener(order)

Prüfen

Genauer, für Neugierige

In C# und JavaScript passiert dieser Fehler nicht, wenn du die eingebauten Mittel benutzt. Das Delegate eines C#-Events ändert sich nicht: -= erzeugt eine neue Liste, und die laufende Benachrichtigung geht über die alte weiter. emit im EventEmitter kopiert die Liste, bevor es die Listener aufruft. Eine eigene Liste musst du von Hand schützen.

Die Idee

Wann du es nicht brauchst

Observer hat seinen Preis. Der Code sagt nicht, wer auf die Zahlung reagiert: Um das herauszufinden, suchst du jede Stelle, die anmeldet. Ein Abonnent, den niemand abmeldet, lebt im Speicher, solange das Subjekt lebt. Es lohnt sich nicht, wenn:

• es eine einzige Reaktion gibt und sie immer dieselbe ist. Ein Aufruf ist klarer als eine Liste mit einem Abonnenten;
• der Schritt Teil der Handlung selbst ist. Ist die Zahlung ohne Rechnung ungültig, ist die Rechnung kein Abonnent: Sie wird direkt aufgerufen, und ihr Scheitern stoppt die Zahlung;
• die Reihenfolge zählt und die Schritte voneinander abhängen (erst das Lager, dann die Zahlung, dann die Rechnung). Das ist eine Abfolge, kein Ereignis. Wie man sie an einer Stelle bündelt, steht in der Lektion „Adapter und Facade“.

Es lohnt sich, wenn die Reaktionen viele sind, wachsen und das Subjekt nicht von ihnen abhängen darf: Benachrichtigungen, Punkte, Statistik, Logs.

Übung

Die Rechnung als Abonnent

Löse die Aufgabe in deinem Editor.

Rechnung. Mach die Rechnung zum Abonnenten: eine Funktion invoice, das den Betrag mit zwei Nachkommastellen ausgibt. Melde E-Mail, das Lager und die Rechnung an und bezahle die Bestellung #1042 über 80 €. Die Zahlungen werden nicht angefasst.

Ausgabe

E-Mail: Beleg für #1042
Lager: reserviere #1042
Rechnung: 80.00 € für #1042

Weitere Aufgaben

• Ein Geschenk über 100 €. Ein Abonnent, der „Geschenk: kostenlose Lieferung für #…“ nur für Bestellungen über 100 € ausgibt. Bezahle eine über 80 € und eine über 120 €.
• Der Gutschein, der sich selbst abmeldet. Schreibe den Gutschein-Abonnenten aus „Finde den Fehler“ und Zahlungen, die damit umgehen. Geh eine Kopie der Liste durch.
• Zwei Ereignisse. Füge auch Erstattungen hinzu. Ein Dictionary Ereignisname → Liste von Abonnenten. E-Mail hört auf beide, das Lager nur auf die Zahlung.

Test

Teste dich

1. Der Shop führt Treuepunkte bei jeder Zahlung ein. Was schreibst du mit Observer?

Eine neue Zeile in der Methode, die die Bestellung als bezahlt markiertEine neue Klasse, die von den Zahlungen erbtEinen neuen Abonnenten, der sich von außen anmeldet; die Zahlungen werden nicht angefasst

2. Der SMS-Abonnent wirft eine Exception, und die Benachrichtigung ist nicht geschützt. Was passiert?

Die Abonnenten danach werden nicht aufgerufen, und der Fehler erreicht den, der die Bestellung als bezahlt markiert hatDas Programm überspringt den FehlerNur die SMS wird nicht gesendet, die anderen Abonnenten arbeiten weiter

3. Derselbe Abonnent ist zweimal angemeldet. Wie oft erfährt er von einer Zahlung?

ZweimalNie: Die zweite Anmeldung hebt die erste aufEinmal: Die Liste hält jeden Abonnenten nur einmal

4. Die Rechnung muss ausgestellt werden, sonst zählt die Zahlung nicht. Passt Observer hier?

Ja, alles nach der Zahlung ist ein AbonnentJa, aber nur, wenn der Abonnent als Erster in der Liste stehtNein: Ein Schritt, ohne den die Zahlung ungültig ist, wird direkt aufgerufen, und sein Scheitern stoppt die Zahlung

Prüfen

Lektion von vorn beginnen

Verwandte Lektionen

• Baut auf: Lambdas · dataclass, match und Muster · Entwurfsmuster · Strategy
• Geht weiter in: Der Shop: welches Muster wohin · Ereignisse und Warteschlangen · Transactional Outbox
• Aufgaben zum Thema: Entwurfsmuster