Was ist das Mediator Pattern und wie hilft es?

Das Mediator Pattern führt eine zentrale Koordination für die Kommunikation zwischen Objekten ein. Statt eines Netzwerks vielfältiger Verweise kommunizieren Komponenten über einen definierten Knoten. Durch diesen Ansatz muss jede Komponente nur noch eine einzige Schnittstelle kennen, wodurch das Netz aus wechselseitigen Abhängigkeiten stark reduziert wird.

Das Problem

Eine Checkout‑Seite kann Warenkorb, Versandformular, Zahlungsformular, Zusammenfassung und Gutscheinfeld enthalten. Wenn jede Komponente jede andere aufruft, wirkt sich jede Änderung auf die gesamte Seite aus. Ein einzelner Eingriff löst dann Kaskadenaufrufe aus, die in entfernten Modulen unerwartete Nebeneffekte hervorrufen. Dies kann zu einem verwirrenden Knäuel von Abhängigkeiten führen, das die Wartbarkeit und Unterhaltbarkeit des Systems erschwert.

Die Lösung mit einem Mediator

interface CheckoutMediator {
  onShippingChanged(method: ShippingMethod): void;
  onCouponApplied(coupon: Coupon): void;
}

class ShippingForm {
  constructor(private mediator: CheckoutMediator) {}

  select(method: ShippingMethod) {
    this.mediator.onShippingChanged(method);
  }
}

class CheckoutCoordinator implements CheckoutMediator {
  onShippingChanged(method: ShippingMethod) {
    // Warenkorb, Zahlung, Zusammenfassung und Berechtigungen koordinieren
  }

  onCouponApplied(coupon: Coupon) {
    // zusammengehörige Aktualisierungen koordinieren
  }
}

Komponenten kennen den Mediator, nicht einander. Der Mediator definiert das Protokoll und koordiniert den Ablauf. Er sorgt dafür, dass Änderungen in einer Komponente korrekt an die anderen weitergeleitet werden, ohne direkte Abhängigkeiten. Damit lässt sich jede Änderung an einer einzelnen Komponente isoliert testen, weil die zugehörige Logik zentral im Mediator ausgelagert ist.

Beispiele

Ein Chatraum vermittelt Nachrichten zwischen Benutzern, sodass Nachrichten ordnungsgemäß geroutet und Benachrichtigungen zentral verwaltet werden. Ein Flughafenkontrollturm koordiniert Flugzeugbewegungen, um eine sichere und effiziente Luftfahrt zu gewährleisten. Ein Formular‑Mediator aktualisiert abhängige Felder, wenn sich Land oder Adresse ändern, um Konsistenz im gesamten Formular aufrechtzuerhalten. Diese Beispiele illustrieren ein Koordinationsmodell, nicht die Behauptung, dass jedes reale System eine einzelne Klasse verwendet.

Vorteile und Risiken

Ein Mediator kann Kopplung reduzieren, Interaktionsregeln zentralisieren und isolierte Tests erleichtern. Allerdings besteht die Hauptgefahr darin, dass sich der Mediator zu einem God Object entwickelt, das Validierung und Geschäftslogik ansammelt. Wird die Logik im Mediator gebündelt, wächst die Klasse schnell, weil jede neue Anforderung weitere Methoden und Zustände erfordert, was die Übersichtlichkeit untergräbt. Dies kann den Mediator zu einem komplexen, schwer zu verwaltenden Objekt machen. Um dies zu vermeiden, sollten Domänenregeln in Domänendiensten oder in den betroffenen Komponenten implementiert werden; der Mediator sollte sich auf die Koordinierung beschränken.

Die zusätzliche Indirektion, die durch den Mediator eingeführt wird, hat ihren Preis. Direkte Aufrufe sind bei einfachen, stabilen Interaktionen klarer, wenn der Mediator keinen offensichtlichen Nutzen bietet. Ein Button, der lediglich einen Boolean umschaltet, profitiert kaum von einer zusätzlichen Vermittlungsschicht; hier ist ein direkter Aufruf effizienter und leichter nachzuvollziehen.

Mediator und Event Bus

Wann es passt

Verwende einen Mediator, wenn mehrere Komponenten komplexen Zustand koordinieren und direkte Referenzen schwierig zu pflegen sind. Vermeide ihn bei unabhängigen Komponenten oder wenn der Mediator fast alles kennen müsste.

Fazit

Das Mediator ersetzt verworrene Peer-to-Peer‑Abhängigkeiten durch einen Knoten. Bleibt der Mediator klein und explizit, verbessert er Lesbarkeit und Testbarkeit erheblich.