Die vier Fallen

Observer ist leicht zu schreiben und leicht falsch zu betreiben. Diese vier Punkte kosten in der Praxis am meisten Zeit — jeder davon in etwa in dieser Reihenfolge der Häufigkeit.

1. Der Abonnent, der nie stirbt

Das ist das bekannteste Problem, und es sieht harmlos aus:

public sealed class BestandsAnzeige
{
    public BestandsAnzeige(Lager lager)
    {
        lager.MindestbestandUnterschritten += Aktualisieren;   // nur angemeldet
    }

    private void Aktualisieren(object? sender, BestandArgs e) { /* ... */ }
}

Mit dem += hält das Lager eine Referenz auf die Anzeige — nicht umgekehrt. Solange das Lager lebt, kann der Garbage Collector die Anzeige nicht einsammeln, auch wenn sie sonst niemand mehr braucht.

Bei einem langlebigen Sender (Singleton, statische Klasse, ein Fenster über der ganzen Sitzung) und kurzlebigen Empfängern ist das ein Leck, das linear mit der Nutzung wächst. Die Handler laufen ausserdem weiter und arbeiten auf Objekten, die längst geschlossen sind.

Die Lösung ist unspektakulär: Was sich anmeldet, meldet sich wieder ab.

public sealed class BestandsAnzeige : IDisposable
{
    private readonly Lager _lager;

    public BestandsAnzeige(Lager lager)
    {
        _lager = lager;
        _lager.MindestbestandUnterschritten += Aktualisieren;
    }

    public void Dispose() => _lager.MindestbestandUnterschritten -= Aktualisieren;

    private void Aktualisieren(object? sender, BestandArgs e) { /* ... */ }
}

2. Ein Handler wirft — und die übrigen laufen nicht mehr

Invoke ruft alle Abonnenten nacheinander in Anmeldereihenfolge auf. Wirft der zweite von vier eine Exception, laufen der dritte und vierte nie, und die Ausnahme landet beim Auslöser — also im Lager, das damit nichts zu tun hat.

Das ist genau der Fehler, den wir in Lektion 1 loswerden wollten: Er ist nur umgezogen.

protected void Melde(BestandArgs e)
{
    foreach (var handler in
        MindestbestandUnterschritten?.GetInvocationList()
            .Cast<EventHandler<BestandArgs>>() ?? [])
    {
        try
        {
            handler(this, e);
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "Abonnent {Handler} ist gescheitert", handler.Method.Name);
        }
    }
}

Das lohnt sich überall dort, wo die Abonnenten voneinander unabhängig sind — und das sind sie beim Observer-Pattern per Definition. Bei einem internen Event mit zwei Handlern aus derselben Klasse wäre es dagegen übertrieben.

3. async void im Handler

Ein EventHandler gibt void zurück. Wer in einem Handler auf etwas warten muss, landet fast automatisch hier:

lager.MindestbestandUnterschritten += async (_, e) =>
{
    await _nachbestellung.BeauftrageAsync(e.Artikel);   // async void
};

Zwei brauchbare Auswege:

• Nur einreihen. Der Handler legt einen Auftrag in eine Queue (Channel<T>, eine Tabelle, ein Message-Broker) und kehrt sofort zurück. Ein Hintergrunddienst arbeitet ihn ab. Das ist die Variante, die in Serveranwendungen fast immer richtig ist.
• Einen eigenen Delegate-Typ verwenden, der Task zurückgibt, und beim Auslösen alle Handler awaiten. Dann ist das Ereignis aber kein event mehr, sondern eine Liste, die du selbst führst.

4. Niemand sieht mehr, was passiert

Die letzte Falle ist keine technische. Bei einem direkten Aufruf kannst du «Gehe zu Definition» drücken. Bei einem Event steht da ?.Invoke — und wer darauf reagiert, entscheidet sich an einer ganz anderen Stelle, oft in einer Konfigurationsdatei oder einem Registrierungsblock.

Das ist der Preis der Entkopplung, und er ist real. Zwei Gegenmittel:

• Ereignisse in der Vergangenheitsform benennen: MindestbestandUnterschritten, BestellungAbgeschlossen, ZahlungEingegangen. Ein Name wie NachbestellungAusloesen verrät, dass es in Wahrheit ein Auftrag ist — und Aufträge ruft man direkt auf.
• Die Anmeldungen zusammenhalten, an einer Stelle im Startcode, statt sie über die Klassen zu verteilen.

Die Kurzfassung