As applications grow, the interaction between components becomes increasingly difficult to manage. Classes end up depending on each other, communication logic spreads throughout the code, and small changes cause unforeseen effects. Mediator Pattern appears exactly to solve this problem.
Mediator Pattern is a behavioral design pattern that centralizes communication between objects, reducing direct dependencies between them and making the system easier to extend and maintain.
What is Mediator Pattern?
Mediator Pattern defines a central object – the mediator – that manages communication between multiple components. Instead of objects communicating directly with each other, they send messages to the mediator, who decides what actions should be triggered.
📌 Key idea:
"Objects no longer talk to each other, but through a mediator."
Thus, each component knows only the mediator, not the other components in the system.
The problem it solves
Without Mediator Pattern:
-
Classes are tightly coupled
-
Communication logic is duplicated
-
Code becomes hard to modify
-
Testing is difficult
With Mediator Pattern:
-
Coupling is reduced
-
Communication is centralized
-
Code becomes clearer and more predictable
-
Components are easier to reuse
Pattern structure
Mediator Pattern consists of:
-
Mediator – the communication interface
-
ConcreteMediator – implements the coordination logic
-
Colleague – components that communicate through the mediator
-
ConcreteColleague – concrete implementations of the components
Practical example in C# (.NET)
Let's take a simple example: an interface with buttons that need to react to each other.
1️⃣ Mediator Interface
public interface IMediator
{
void Notify(object sender, string @event);
}
2️⃣ Concrete Mediator
public class DialogMediator : IMediator
{
public Button SaveButton { get; set; }
public Button CancelButton { get; set; }
public void Notify(object sender, string @event)
{
if (@event == "SaveClicked")
{
CancelButton.Disable();
}
else if (@event == "CancelClicked")
{
SaveButton.Disable();
}
}
}
3️⃣ Components (Colleagues)
public class Button
{
private readonly IMediator _mediator;
public string Name { get; }
public Button(IMediator mediator, string name)
{
_mediator = mediator;
Name = name;
}
public void Click()
{
_mediator.Notify(this, $"{Name}Clicked");
}
public void Disable()
{
Console.WriteLine($"{Name} disabled");
}
}
4️⃣ Using the mediator
var mediator = new DialogMediator();
var saveButton = new Button(mediator, "Save");
var cancelButton = new Button(mediator, "Cancel");
mediator.SaveButton = saveButton;
mediator.CancelButton = cancelButton;
saveButton.Click(); // Cancel disabled
cancelButton.Click(); // Save disabled
✔ Buttons know nothing about each other
✔ All logic is centralized
✔ Code is easier to extend
Mediator Pattern in real applications
Mediator Pattern is extremely useful in:
-
UI applications (WinForms, WPF, MAUI, Blazor)
-
Notification systems
-
Business workflows
-
Modules that need to collaborate without direct dependencies
-
Event-driven systems
In .NET, the pattern is often encountered in the form of:
-
Event Aggregator
-
Message Bus
-
MediatR (a very popular library)
Advantages
✅ Reduces coupling between components
✅ Centralizes communication logic
✅ Easier to maintain code
✅ Simpler testing
✅ Reusable components
Disadvantages
⚠️ The mediator can become too complex
⚠️ Risk of "God Object" if not well structured
👉 Solution: clear separation of responsibilities and specialized mediators.
Mediator Pattern vs Observer Pattern
-
Observer: one-to-many communication, passive
-
Mediator: active coordination, centralized logic
In practice, the two patterns are often combined.
Conclusion
Mediator Pattern is an elegant solution for complex systems where objects need to collaborate without being tightly coupled. If you feel your application is starting to look like a "web" of dependencies, the mediator is often the right answer.
