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 {
    private final EmailService email = new EmailService();
    private final SmsService sms = new SmsService();
    private final Warehouse warehouse = new Warehouse();
    private final InvoiceService invoices = new InvoiceService();

    public void markPaid(Order order) {
        email.sendReceipt(order);
        sms.notifyPaid(order);
        warehouse.reserve(order);
        invoices.issue(order);
    }
}

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

Payments payments = new Payments();
payments.markPaid(new 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 markPaid. 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 {
    public void notifyPaid(Order order) {
        throw new IllegalStateException("Das SMS-Gateway antwortet nicht");
    }
}

Payments payments = new Payments();
try {
    payments.markPaid(new Order(1042, 80));
} catch (IllegalStateException e) {
    System.out.println("Zahlung fehlgeschlagen: " + e.getMessage());
}

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: ein Interface mit einer Methode, 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

Ein Abonnent ist ein PaidListener. Die Zahlungen halten eine Liste davon:

record Order(int id, double total) {}

interface PaidListener {
    void paid(Order order);
}

class Payments {
    private final List<PaidListener> listeners = new ArrayList<>();

    public void subscribe(PaidListener listener) {
        listeners.add(listener);
    }

    public void unsubscribe(PaidListener listener) {
        listeners.remove(listener);
    }

    public void markPaid(Order order) {
        for (PaidListener listener : listeners) {
            listener.paid(order);
        }
    }
}

PaidListener hat eine Methode, also kann jeder Abonnent ein Lambda sein:

PaidListener email = order -> System.out.println("E-Mail: Beleg für #" + order.id());
PaidListener sms = order -> System.out.println("SMS: Bestellung #" + order.id() + " ist bezahlt");
PaidListener warehouse = order -> System.out.println("Lager: reserviere #" + order.id());
PaidListener loyalty = order -> System.out.println("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 = new Payments();
payments.subscribe(email);
payments.subscribe(sms);
payments.subscribe(warehouse);
payments.markPaid(new Order(1042, 80));

payments.subscribe(loyalty);
payments.unsubscribe(sms);
payments.markPaid(new 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 = new Payments();
payments.subscribe(email);
payments.subscribe(sms);
payments.subscribe(warehouse);
payments.markPaid(new Order(1042, 80));

payments.subscribe(loyalty);
payments.unsubscribe(sms);
payments.markPaid(new 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 auch eine Methodenreferenz sein: payments.subscribe(mailer::sendReceipt). Aber jedes mailer::sendReceipt erzeugt ein neues Objekt. unsubscribe mit einem neuen :: findet das alte in der Liste nicht und entfernt nichts:

Payments payments = new Payments();
EmailService mailer = new EmailService();
payments.subscribe(mailer::sendReceipt);
payments.unsubscribe(mailer::sendReceipt);
payments.markPaid(new Order(1042, 80));

Ausgabe

E-Mail: Beleg für #1042

Einen Abonnenten, den du abmelden willst, hältst du also in einer Variablen, wie sms oben.

• Die Abonnenten werden nacheinander im selben Aufruf von markPaid 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:

PaidListener sms = order -> {
    throw new IllegalStateException("Das SMS-Gateway antwortet nicht");
};

Payments payments = new Payments();
payments.subscribe(email);
payments.subscribe(sms);
payments.subscribe(warehouse);
try {
    payments.markPaid(new Order(1042, 80));
} catch (IllegalStateException e) {
    System.out.println("Zahlung fehlgeschlagen: " + e.getMessage());
}

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:

public void markPaid(Order order) {
    for (PaidListener listener : listeners) {
        try {
            listener.paid(order);
        } catch (RuntimeException e) {
            System.out.println("Ein Abonnent ist fehlgeschlagen: " + e.getMessage());
        }
    }
}

Mit demselben Programm:

Payments payments = new Payments();
payments.subscribe(email);
payments.subscribe(sms);
payments.subscribe(warehouse);
try {
    payments.markPaid(new Order(1042, 80));
} catch (IllegalStateException e) {
    System.out.println("Zahlung fehlgeschlagen: " + e.getMessage());
}

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 = new Payments();
payments.subscribe(email);
payments.subscribe(warehouse);
payments.subscribe(email);
payments.markPaid(new Order(7, 10));

payments.unsubscribe(warehouse);
payments.markPaid(new Order(8, 10));

Antwort

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

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 #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:

class WelcomeCoupon implements PaidListener {
    private final Payments payments;

    public WelcomeCoupon(Payments payments) {
        this.payments = payments;
    }

    @Override
    public void paid(Order order) {
        System.out.println("Willkommensgutschein: #" + order.id());
        payments.unsubscribe(this);
    }
}

Payments payments = new Payments();
payments.subscribe(new WelcomeCoupon(payments));
payments.subscribe(email);
payments.subscribe(warehouse);
payments.markPaid(new Order(1042, 80));
payments.markPaid(new Order(1043, 25));

Fehler

Willkommensgutschein: #1042
Exception in thread "main" java.util.ConcurrentModificationException

Die erste Bestellung hat den Gutschein bekommen, und dann ist das Programm abgebrochen. In welcher Zeile von Payments steckt der Fehler?

Wähle die Zeile mit dem Fehler.

1class Payments {2 private final List<PaidListener> listeners = new ArrayList<>();34 public void subscribe(PaidListener listener) {5 listeners.add(listener);6 }78 public void unsubscribe(PaidListener listener) {9 listeners.remove(listener);10 }1112 public void markPaid(Order order) {13 for (PaidListener listener : listeners) {14 listener.paid(order);15 }16 }17}

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: ein Lambda invoice vom Typ PaidListener, 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. Eine zweite Liste von Abonnenten und eine Methode markRefunded. 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 · record, switch und Muster · Entwurfsmuster · Strategy
• Geht weiter in: Der Shop: welches Muster wohin · Ereignisse und Warteschlangen · Transactional Outbox
• Aufgaben zum Thema: Entwurfsmuster