Mediator-Entwurfsmuster - Versionsgeschichte

PhilKa am 8. November 2025 um 13:05 Uhr

2025-11-08T13:05:42Z

← Nächstältere Version		Version vom 8. November 2025, 15:05 Uhr
Zeile 1:		Zeile 1:
	= Mediator-Entwurfsmuster =		= Mediator-Entwurfsmuster =

	Das '''Mediator-Entwurfsmuster''' ist ein Verhaltensmuster aus der Softwareentwicklung.		Das '''Mediator-Entwurfsmuster''' ist ein ''Verhaltensmuster'' aus der Softwareentwicklung.
	Es dient dazu, die Kommunikation zwischen Objekten zu zentralisieren, indem ein Vermittlerobjekt (Mediator) die Interaktionen koordiniert. Dadurch werden direkte Abhängigkeiten zwischen den beteiligten Objekten reduziert und das System bleibt übersichtlicher, entkoppelter und leichter wartbar.		Es dient dazu, die ''Kommunikation zwischen Objekten zu zentralisieren'', indem ein Vermittlerobjekt (Mediator) die Interaktionen koordiniert. Dadurch werden direkte Abhängigkeiten zwischen den beteiligten Objekten reduziert und das System bleibt ''übersichtlicher, entkoppelter und leichter wartbar''.

	== Ziel ==		== Ziel ==
	Das Mediator-Muster soll:		Das Mediator-Muster soll:
	* Abhängigkeiten zwischen Klassen reduzieren		* ''Abhängigkeiten zwischen Klassen reduzieren''
	* Komplexität der Kommunikation vereinfachen		* ''Komplexität der Kommunikation vereinfachen''
	* Änderungen lokal halten, ohne viele Klassen anpassen zu müssen		* ''Änderungen lokal halten'', ohne viele Klassen anpassen zu müssen
	* Code lesbarer und modularer gestalten		* ''Code lesbarer und modularer gestalten''

	== Problemstellung ==		== Problemstellung ==
	Ohne Mediator kommunizieren Objekte oft direkt miteinander.		Ohne Mediator kommunizieren Objekte oft ''direkt miteinander''.
	In Systemen mit vielen Objekten führt dies zu:		In Systemen mit vielen Objekten führt dies zu:
	* komplexen Abhängigkeiten,		* komplexen Abhängigkeiten,
Zeile 18:		Zeile 18:
	* hoher Kopplung.		* hoher Kopplung.

	Das Mediator-Muster löst dies, indem alle Kommunikation über eine zentrale Instanz läuft.		Das Mediator-Muster löst dies, indem ''alle Kommunikation über eine zentrale Instanz'' läuft.

	== Grundidee ==		== Grundidee ==
	Statt dass Objekte sich gegenseitig direkt aufrufen, informieren sie den Mediator.		Statt dass Objekte sich gegenseitig direkt aufrufen, informieren sie ''den Mediator''.
	Dieser entscheidet dann, welches Objekt darauf reagieren soll.		Dieser entscheidet dann, welches Objekt darauf reagieren soll.

Zeile 40:		Zeile 40:
	! Komponente !! Beschreibung		! Komponente !! Beschreibung
	\|-		\|-
	\| Mediator \|\| Vermittelt und koordiniert die Kommunikation zwischen Objekten.		\| ''Mediator'' \|\| Vermittelt und koordiniert die Kommunikation zwischen Objekten.
	\|-		\|-
	\| ConcreteMediator \|\| Konkrete Implementierung der Vermittlungslogik.		\| ''ConcreteMediator'' \|\| Konkrete Implementierung der Vermittlungslogik.
	\|-		\|-
	\| Colleague \|\| Objekt, das mit anderen kommunizieren möchte, jedoch nur den Mediator kontaktiert.		\| ''Colleague'' \|\| Objekt, das mit anderen kommunizieren möchte, jedoch nur den Mediator kontaktiert.
	\|-		\|-
	\| ConcreteColleague \|\| Konkrete Klassen, die Nachrichten über den Mediator senden.		\| ''ConcreteColleague'' \|\| Konkrete Klassen, die Nachrichten über den Mediator senden.
	\|}		\|}

Zeile 115:		Zeile 115:

	== Vorteile ==		== Vorteile ==
	* Verringerte Kopplung zwischen Objekten		* ''Verringerte Kopplung'' zwischen Objekten
	* Zentrale Steuerung des Kommunikationsverhaltens		* ''Zentrale Steuerung'' des Kommunikationsverhaltens
	* Leichtere Erweiterbarkeit, da Änderungen nur im Mediator erfolgen		* ''Leichtere Erweiterbarkeit'', da Änderungen nur im Mediator erfolgen
	* Übersichtliche Struktur bei vielen interagierenden Komponenten		* ''Übersichtliche Struktur'' bei vielen interagierenden Komponenten

	== Nachteile ==		== Nachteile ==
	* Mediator kann komplex werden, wenn viele Regeln zentralisiert sind		* ''Mediator kann komplex werden'', wenn viele Regeln zentralisiert sind
	* Gefahr eines „God Object“, das zu viel Logik übernimmt		* Gefahr eines ''„God Object“'', das zu viel Logik übernimmt
	* Verteilung der Verantwortlichkeiten muss klar definiert werden		* Verteilung der Verantwortlichkeiten muss ''klar definiert'' werden

	== Einsatzgebiete ==		== Einsatzgebiete ==
Zeile 129:		Zeile 129:
	* viele Objekte miteinander interagieren,		* viele Objekte miteinander interagieren,
	* die Kommunikationslogik häufig geändert wird,		* die Kommunikationslogik häufig geändert wird,
	* eine klare Trennung von Logik und Kommunikationsregeln erforderlich ist.		* eine klare Trennung von ''Logik'' und ''Kommunikationsregeln'' erforderlich ist.

	Typische Anwendungsfälle:		Typische Anwendungsfälle:
	* GUI-Systeme (z. B. Dialog- und UI-Steuerung)		* ''GUI-Systeme'' (z. B. Dialog- und UI-Steuerung)
	* Chat- oder Messaging-Systeme		* ''Chat- oder Messaging-Systeme''
	* Event-Handling in komplexen Softwarekomponenten		* ''Event-Handling in komplexen Softwarekomponenten''
	* Microservice-Orchestrierung		* ''Microservice-Orchestrierung''

	== Zusammenfassung ==		== Zusammenfassung ==

PhilKa: Die Seite wurde neu angelegt: „= Mediator-Entwurfsmuster = Das '''Mediator-Entwurfsmuster''' ist ein Verhaltensmuster aus der Softwareentwicklung. Es dient dazu, die Kommunikation zwischen Objekten zu zentralisieren, indem ein Vermittlerobjekt (Mediator) die Interaktionen koordiniert. Dadurch werden direkte Abhängigkeiten zwischen den beteiligten Objekten reduziert und das System bleibt übersichtlicher, entkoppelter und leichter wartbar. == Ziel == Das Mediator-Muster…“

2025-11-08T12:58:28Z

Die Seite wurde neu angelegt: „= Mediator-Entwurfsmuster = Das '''Mediator-Entwurfsmuster''' ist ein **Verhaltensmuster** aus der Softwareentwicklung. Es dient dazu, die **Kommunikation zwischen Objekten zu zentralisieren**, indem ein Vermittlerobjekt (Mediator) die Interaktionen koordiniert. Dadurch werden direkte Abhängigkeiten zwischen den beteiligten Objekten reduziert und das System bleibt **übersichtlicher, entkoppelter und leichter wartbar**. == Ziel == Das Mediator-Muster…“

Neue Seite

= Mediator-Entwurfsmuster =

Das '''Mediator-Entwurfsmuster''' ist ein **Verhaltensmuster** aus der Softwareentwicklung.
Es dient dazu, die **Kommunikation zwischen Objekten zu zentralisieren**, indem ein Vermittlerobjekt (Mediator) die Interaktionen koordiniert. Dadurch werden direkte Abhängigkeiten zwischen den beteiligten Objekten reduziert und das System bleibt **übersichtlicher, entkoppelter und leichter wartbar**.

== Ziel ==
Das Mediator-Muster soll:
* **Abhängigkeiten zwischen Klassen reduzieren**
* **Komplexität der Kommunikation vereinfachen**
* **Änderungen lokal halten**, ohne viele Klassen anpassen zu müssen
* **Code lesbarer und modularer gestalten**

== Problemstellung ==
Ohne Mediator kommunizieren Objekte oft **direkt miteinander**.
In Systemen mit vielen Objekten führt dies zu:
* komplexen Abhängigkeiten,
* schwerer Wartbarkeit,
* hoher Kopplung.

Das Mediator-Muster löst dies, indem **alle Kommunikation über eine zentrale Instanz** läuft.

== Grundidee ==
Statt dass Objekte sich gegenseitig direkt aufrufen, informieren sie **den Mediator**.
Dieser entscheidet dann, welches Objekt darauf reagieren soll.

=== Prinzipielle Darstellung ===
<pre>
Vorher (hohe Kopplung):
Objekt A <--> Objekt B <--> Objekt C

Nachher (mit Mediator):
Objekt A --> Mediator <-- Objekt B
^
|
Objekt C
</pre>

== Kernbestandteile ==
{| class="wikitable"
! Komponente !! Beschreibung
|-
| **Mediator** || Vermittelt und koordiniert die Kommunikation zwischen Objekten.
|-
| **ConcreteMediator** || Konkrete Implementierung der Vermittlungslogik.
|-
| **Colleague** || Objekt, das mit anderen kommunizieren möchte, jedoch nur den Mediator kontaktiert.
|-
| **ConcreteColleague** || Konkrete Klassen, die Nachrichten über den Mediator senden.
|}

== Beispiel in C++ ==
<syntaxhighlight lang="cpp">
#include <iostream>
#include <string>

class Mediator;

class Colleague {
protected:
Mediator* mediator;
public:
Colleague(Mediator* m) : mediator(m) {}
virtual void receive(const std::string& msg) = 0;
void send(const std::string& msg);
};

class Mediator {
public:
virtual void distribute(Colleague* sender, const std::string& msg) = 0;
};

void Colleague::send(const std::string& msg) {
mediator->distribute(this, msg);
}

class ConcreteColleagueA : public Colleague {
public:
using Colleague::Colleague;
void receive(const std::string& msg) override {
std::cout << "A empfängt: " << msg << std::endl;
}
};

class ConcreteColleagueB : public Colleague {
public:
using Colleague::Colleague;
void receive(const std::string& msg) override {
std::cout << "B empfängt: " << msg << std::endl;
}
};

class ConcreteMediator : public Mediator {
private:
Colleague* a;
Colleague* b;
public:
ConcreteMediator(Colleague* a, Colleague* b) : a(a), b(b) {}
void distribute(Colleague* sender, const std::string& msg) override {
if (sender == a) b->receive(msg);
else a->receive(msg);
}
};

int main() {
ConcreteColleagueA a(nullptr);
ConcreteColleagueB b(nullptr);
ConcreteMediator m(&a, &b);
a = ConcreteColleagueA(&m);
b = ConcreteColleagueB(&m);

a.send("Hallo von A!");
b.send("Hallo von B!");
}
</syntaxhighlight>

== Vorteile ==
* **Verringerte Kopplung** zwischen Objekten
* **Zentrale Steuerung** des Kommunikationsverhaltens
* **Leichtere Erweiterbarkeit**, da Änderungen nur im Mediator erfolgen
* **Übersichtliche Struktur** bei vielen interagierenden Komponenten

== Nachteile ==
* **Mediator kann komplex werden**, wenn viele Regeln zentralisiert sind
* Gefahr eines **„God Object“**, das zu viel Logik übernimmt
* Verteilung der Verantwortlichkeiten muss **klar definiert** werden

== Einsatzgebiete ==
Das Mediator-Muster wird eingesetzt, wenn:
* viele Objekte miteinander interagieren,
* die Kommunikationslogik häufig geändert wird,
* eine klare Trennung von **Logik** und **Kommunikationsregeln** erforderlich ist.

Typische Anwendungsfälle:
* **GUI-Systeme** (z. B. Dialog- und UI-Steuerung)
* **Chat- oder Messaging-Systeme**
* **Event-Handling in komplexen Softwarekomponenten**
* **Microservice-Orchestrierung**

== Zusammenfassung ==
Das Mediator-Entwurfsmuster zentralisiert die Kommunikation zwischen Objekten, reduziert Kopplung und verbessert die Wartbarkeit komplexer Systeme. Es ist besonders geeignet für Anwendungen mit vielen interagierenden Komponenten, muss jedoch sorgfältig gestaltet werden, um eine Überlastung des Mediators zu vermeiden.

== Siehe auch ==
* [[Observer-Entwurfsmuster]]
* [[Strategy-Entwurfsmuster]]
* [[Command-Entwurfsmuster]]
* [[Entwurfsmuster in der Softwareentwicklung]]

== Weblinks ==
* https://en.wikipedia.org/wiki/Mediator_pattern
* https://refactoring.guru/design-patterns/mediator