Mediator Design Pattern
|Mediator Use Case|
Objects communicate through the Mediator rather than directly with each other.
As a system evolves and becomes larger and supports more complex functionality and business rules, the problem of communicating between these components becomes more complicated to understand and manage. It may be beneficial to refactor your system to centralize some or all of its functionality via some kind of mediation process.
The mediator pattern is similar to implementing the Facade pattern between your objects and processes. Except that the structure of the Mediator could also allow multi-directional communication between each component and provide the opportunity to add some logic to the messaging flow to make it more cooperative in some way. E.g., managing the routing behavior by serializing or batching messages, the centralization of application logic, caching, logging, etc.
- Mediator: The coordinator of communications between the components (colleagues).
- Colleagues: One of the many types of concrete components that use the mediator.
Mediator UML Diagram
In the example concept, there are two colleague classes that use each other's methods. Instead of the Colleagues calling each other's methods directly, they implement the Mediator interface and call each other via the Mediator. Each colleague is designed for a different purpose, but they utilize some related functionality from each other.
The system, in this case, would work without the Mediator, but adding the Mediator would allow extending functionality to a potential third colleague that provides a different service, such as AI analysis or monitoring, without needing to add specific support or knowledge into the two original colleagues.
In this first example the Mediator is structurally acting as a multi-directional relay between the two colleagues.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
node ./dist/mediator/mediator-concept.js COLLEAGUE1 <--> Here is the Colleague2 specific data you asked for COLLEAGUE2 <--> Here is the Colleague1 specific data you asked for
Mediator Use Case
In this example use case, we will implement some behavior into the mediation process.
Before the mediation logic is added, consider that the below example is a series of components all subscribed to a central location being the subject. They all implement the Observer pattern.
Each component is updated independently by external forces, but when it has new information, it notifies the subject which in turn then notifies the other subscribed components.
During the synchronization of all the subscribed components, without the extra mediation, the component that provided the new information will receive back the same message that it just notified the subject of. In order to manage the unnecessary duplicate message, the notifications will be mediated to exclude to component where the original message originated from.
Example UML Diagram
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
1 2 3 4 5 6 7
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
node ./dist/mediator/client.js Component1: >>> Out >>> : data A Component2: <<< In <<< : data A Component3: <<< In <<< : data A Component2: >>> Out >>> : data B Component1: <<< In <<< : data B Component3: <<< In <<< : data B Component3: >>> Out >>> : data C Component1: <<< In <<< : data C Component2: <<< In <<< : data C
- A mediator replaces a structure with many-to-many interactions between its classes and processes, with a one-to-many centralized structure where the interface supports all the methods of the many-to-many structure, but via the mediator component instead.
- The mediator pattern encourages usage of shared objects that can now be centrally managed and synchronized.
- The mediator pattern creates an abstraction between two or more components that then makes a system easier to understand and manage.
- The mediator pattern is similar to the Facade pattern, except the Mediator can also transact data both ways between two or more other classes or processes that would normally interact directly with each other.