Mediator is a behavioral design pattern: 🖤🖤🖤🤍🤍
What is Mediator?
Mediator (Loudspeaker) is a behavioral design pattern that allows communication between objects without them having to refer to each other directly. Instead, all communication is handled by a central object called the mediator.
In this pattern, the mediator acts as an intermediary between the objects that need to communicate with each other. The objects don’t have to know anything about each other, and they don’t need to hold any references to each other.
Why use Mediator?
The Mediator pattern has the following advantages and disadvantages:
- Simplifies communication between objects
- Reduces coupling between objects
- Centralizes control of communication
- Can lead to the creation of a “God” object that knows too much about the system
- Can add complexity to the system
Question: I hate the Mediator pattern, what are the alternatives?
Answer: The alternative is to have the objects communicate with each other directly. However, this can lead to increased coupling and reduced flexibility.
When to use Mediator?
Question: When should I use Mediator?
Answer: The Mediator pattern is useful when you have a complex system with many components that need to communicate with each other, and you want to minimize the dependencies between those components. It can improve flexibility, reduce complexity, and enforce encapsulation.
The Mediator and Observer patterns are both used to manage communication between objects in a system, but they differ in how they manage that communication.
In the Observer pattern, the responsibility for managing communication is divided between two types of objects: subjects and observers. The subject maintains a list of observers that need to be notified of changes to its state, and when its state changes, it sends notifications to all registered observers, updating them accordingly. Observers have no knowledge of each other and communicate only with the subject.
In contrast, the Mediator pattern defines an object (the mediator) that acts as a central hub for communication between objects. Objects communicate with each other via the mediator, which encapsulates the logic for how they interact with each other. The mediator has knowledge of all the objects that need to communicate with each other and can control the communication flow between them.
So, the key difference between the Mediator and Observer patterns is that in the Mediator pattern, the mediator object manages the communication flow between objects, while in the Observer pattern, the subject object manages the communication flow between itself and its observers.
You have a room that contains many students, who may speak or listen.
If one student wants to say something, there is a simple way to let him notify the whole room.
How to implement Mediator?
One way we could do this is by having each student communicate with each other directly, like so:
This approach works, but it quickly becomes unwieldy as the number of students grows. Each student would need to have a reference to every other student in the group, which becomes difficult to manage and maintain as the group size grows.
Instead of having each student communicate with each other directly, we can introduce a Mediator class that manages the communication between them.
The LoudSpeaker object acts as a mediator, allowing the Student objects to communicate with each other without directly referencing each other.
The Mediator pattern provides a way to manage complex communication between objects in a group. By introducing a Mediator class, we can simplify the communication between objects and avoid the need for each object to have a reference to every other object in the group. This makes it easier to manage and maintain the group, especially as its size grows.
In summary, the Mediator pattern:
- Simplifies communication between objects in a group
- Avoids the need for each object to have a reference to every other object in the group
- Makes it easier to manage and maintain the group, especially as its size grows