Mediator | Cheat Sheet
Behavioral Pattern — Design Patterns Series
A Mediator controls the interaction of different object groups. A real life example is a chat room in which different users write to each other. The chat room or server is the Mediator object that manages users and distributes the messages to different clients.
The pattern helps to loose coupling by preventing explicit referencing of participants. The user in a chat room does not know the direct reference of another user. She/he only knows the server and another user’s id. The responsibility of the Mediator is to forward messages to the correct receiver. So, hundreds of users can be in a room and all objects are loosely coupled.
This causes the Mediator to have individual control of all interactions of the users / object groups — a centralized control.
Real-life examples
- Air traffic control through tower
- Chat room (websockets communicate with server; server is Mediator object)
- Taxi radio (call centre is Mediator object)
- Mapper in Enterprise Applications (separates different subsystems that should / want to communicate with each other)
- Framework examples like VerneMQ, Kafka
Meaning
- Definition of an object that controls the interaction of object groups
- Mediator favors loose coupling by preventing explicit referencing of participants and allowing individual control of their interactions
Applicability (suitable if …)
- Communication within an object group is well-defined, but also in a complex way (dependencies are unstructured and difficult to understand)
- Reusability of objects is difficult because it references and communicates with numerous other objects
- Adaptability of distributed behavior across several classes is supposed to be ensured
Assets and Drawbacks
- Restricted subclassing of the mediator for behavior change
- Decoupling of participant objects — this allows them to be varied and reused independently of each other
- Simplification of object control (n:n becomes 1:n) — Easier object management (understanding, expansion, and more)
- Abstraction of object cooperation
- Centralised control — complexity of interactions is exchanged for complexity of the mediator (monolithic approach)
Example
A chat room is a good real life example where the Mediator pattern comes into play. Different users communicate with a server — and this server is the Mediator which distributes the messages to different user. So, users can communicate through the server, and they can be added to a room and can get notified.
The chat room (Mediator) manages all users and sends messages between different users with a notify function.
A user can send and receive messages. Also, the user knows his Mediator object.
If the user wants to interact with another user, she/he sends the user id and a message to the Mediator (server), which then forwards the message to the user with the given id.
The client only needs to initiate an object of a chat room and add users who want to write each other.
Conclusion
Design Patterns are an important resource and base knowledge for every developer — they are very helpful for solving programmatic problems, help with consistent communication with other developers about system design, and serve as a significant introduction into object composition (besides inheritance) and dependency inversion.
Behavioral Patterns deal with algorithms and assignment of responsibilities to objects. Furthermore, they describe mutual communication patterns and grasp complex program sequences. They are therefore very well suited for use in areas where complicated code needs to be made readable and maintainable. Extensions are, in consequence, very good and quickly implementable.
