1. Motivation
- In the process of software construction, multiple objects often interact with each other, and a complex reference relationship is often maintained between objects. If some requirements change, this direct reference relationship will face constant changes. .
- In this case, we can use an "intermediary object" to manage the relationship between objects, avoid the tightly coupled reference relationship between interacting objects, and better resist changes.
Example:
There are a lot of controls on the interface. At this time, you usually hope that when you change the state of the interface controls, there may be your data DataModel behind it and you want to change it accordingly. Similarly, if your DataModel changes, your interface also hopes Follow the changes. This situation will lead to a two-way direct dependency, that is, interface elements need to reference DadaModel objects, and data objects may also need to reference interface elements. This is definitely not appropriate. For example, if interface elements are replaced later, the modification cost is very high.
2. Schema definition
Use an intermediary object to encapsulate (encapsulate changes) a series of object interactions. Mediators make objects not need to explicitly refer to each other (compile-time dependencies -> runtime dependencies), thus making them loosely coupled (manage changes), and their interactions can be changed independently.
----《Design Patterns》GOF
3. Structure
In the figure above, ConcreteColleague1 and ConcreteColleague2 are directly dependent, but there is no dependency relationship between the Colleagues in the figure above. They all depend on Mediator. In turn, Mediator internally depends on Colleague, so Colleague and Mediartor are directly two-way dependent.
But in reality, ConcreteColleague1 and ConcreteColleague2 are often not the inheritance relationship in the above figure, such as the previous components and DataBase.
A more understandable graph representation:
For example, in the above dependency relationship, the nodes represented by numbers are all Colleagues in the above structure diagram, which is modified to:
Some netizens said that M is a bit like "property" , very image! !
This mode is somewhat similar to the Facade mode. They both propose new classes for isolation. Facade solves the isolation outside the system and within the system, and the intermediary solves the isolation of various classes in the system.
4. Summary
- Decoupling the complex relationship between multiple objects, the Mediator mode centrally manages the control logic between multiple objects, changing "multiple objects are associated with each other" to "multiple objects are associated with a mediator", which simplifies the system. Maintained against possible changes.
- With the complexity of the control logic, the implementation of the Mediator concrete object may be quite complicated. At this time, you can decompose the Mediator object for you
- Facade mode is to decouple the (one-way) object association between systems; Mediator mode is to decouple the (two-way) association between objects in the system.