Mediator Pattern
- handles many-to-many interactions
- is a behavioral design patternthat lets you reduce chaotic dependencies between objects. The pattern restricts direct communications between the objects and forces them to collaborate only via a mediator object
Real-World Examples
User-Group Operating System
An example where Mediator is useful is the design of a user and group capability in an operating system. A group can have zero or more users, and, a user can be a member of zero or more groups. The Mediator pattern provides a flexible and non-invasive way to associate and manage users and groups
Code Example
User-Group Operating System
TODO
Code Structure
/behavioral-design-patterns/mediator-pattern/mediator-structure.png)
Comparisons
Click here to expand...
Link to originalChain of Responsibility, Command, Mediator, and Observer address various ways of connecting senders and receivers of requests:
- Chain of Responsibility passes a request sequentially along a dynamic chain of potential receivers until one of them handles it
- Command establishes unidirectional connections between senders and receivers
- Mediator eliminates direct connections between senders and receivers, forcing them to communicate indirectly via a mediator object
- Observer lets receivers dynamically subscribe to and unsubscribe from receiving requests
Link to originalFacade Pattern and Mediator Pattern have similar jobs: they try to organize collaboration between lots of tightly coupled classes.
- Facade defines a simplified interface to a subsystem of objects, but it doesn’t introduce any new functionality. The subsystem itself is unaware of the facade. Objects within the subsystem can communicate directly
- Mediator centralizes communication between components of the system. The components only know about the mediator object and don’t communicate directly
- both abstracts the functionality of existing classes:
- Mediator abstracts/centralizes arbitrary communications between colleague objects. It routinely “adds value”, and it is known/referenced by the colleague objects. In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes
Link to originalMediator Pattern and Observer Pattern (Publisher-Subscriber Pattern) differences are often elusive. In most cases, you can implement either of these patterns; but sometimes you can apply both simultaneously. Let’s see how we can do that.
- The primary goal of Mediator is to eliminate mutual dependencies among a set of system components. Instead, these components become dependent on a single mediator object. The goal of Observer is to establish dynamic one-way connections between objects, where some objects act as subordinates of others
- There’s a popular implementation of the Mediator pattern that relies on Observer. The mediator object plays the role of publisher, and the components act as subscribers which subscribe to and unsubscribe from the mediator’s events. When Mediator is implemented this way, it may look very similar to Observer.
- When you’re confused, remember that you can implement the Mediator pattern in other ways. For example, you can permanently link all the components to the same mediator object. This implementation won’t resemble Observer but will still be an instance of the Mediator pattern.
- Now imagine a program where all components have become publishers, allowing dynamic connections between each other. There won’t be a centralized mediator object, only a distributed set of observers.