Mediator

Mediators belong to the behavior mode.

Intent: A mediation object encapsulates a set of object interactions. The mediator loosens the coupling of objects by eliminating the need to explicitly refer to each other, and can change their interactions independently.

In front-end development, the most commonly used “data driven” is actually the best interpretation of the mediator pattern.

Think of a scenario like this:

  1. After the button is clicked, the form is submitted. The button needs to call all the form items to get the form value.
  2. Form association. When the city is checked, the satisfaction Input box will appear. At this time, the city tick button needs to reference the satisfaction Input box.
  3. There are even circular references, where the two input fields are mutually exclusive, and if you enter one, the other field will Disable.
  4. When a new form item is added, all references need to be re-established.

Maintaining large projects is almost impossible with procedural programming. All form items depend on the data and modify the data. Therefore, when the Input box is linked to the Checkbox, the Input does not need to sense the existence of the Checkbox. It only needs to associate the data and modify the data. Checkbox also only needs to associate data and modify data, so that not only the logic can be done independently, but also can solve the problem of circular reference.

In the data-driven case, the data is the mediator. Instead of referring to each other, all uIs work together through the mediation of data, which has the obvious benefit of handling complex projects and being easy to maintain.

For example,

If you don’t understand the above description, it doesn’t matter. Design patterns need to be used in daily work. Examples will help you understand better.

Data driven

As mentioned earlier, data-driven is a classic example of a mediator, and it is the introduction of a “data mediator” that allows the front-end project to increase geometrically in complexity, while the logic of code increases only linearly. Because the UI is cluttered and dynamic, inter-UI dependencies can lead to complex relationships, and once relationships are formed, adding new elements or modifying them becomes extremely difficult.

The mediator mode avoids the dependent relationships between UIs and can greatly reduce the logic complexity through unified scheduling of data layer and controlled response of UI.

Resolving circular dependencies

Circular dependencies can almost only be resolved with the intermediary pattern:

import { b } from './b'
export const a = 'a'
Copy the code
import { a } from './a'
export const b = 'b'
Copy the code

Creating circular dependencies when two parties refer to each other is problematic not only for modularity, but also logically unsound, because there must be a problem with recursive calls. Therefore, the introduction of third-party intermediaries is not only a design mode of thinking, but there are some contents in modules A and B that are common to both sides and must be proposed, and the unified proposed place is the intermediary part of the intermediary mode.

Enterprise organizational structure

A tree in the enterprise organization structure, each a leaf node is broker, need to give him the child nodes of the assigned task, and coordinate their work, as a result, the leaf nodes do not need to have a holistic view can get a job, because they need to be responsible for the “to do your own thing”, and don’t need to care about how “together”.

As shown in the figure, the environment Department does not need to care about what the personnel department does, as long as they focus on environmental affairs. The coordination between them is handled by the general manager, which is a manifestation of division of labor and collaboration.

And only exists in the theory of network enterprise management model, it is no broker example, all nodes are leaf nodes, and reference each other, so everyone should do his own work, and to deal with their coordination with other tens of thousands of people in the company, is almost impossible thing, so from the Angle of design patterns, They also tend to use a tree rather than a mesh model to manage their business.

Intention to explain

Intent: A mediation object encapsulates a set of object interactions. The mediator loosens the coupling of objects by eliminating the need to explicitly refer to each other, and can change their interactions independently.

The mediator pattern is easy to understand, literally. By object interaction, we mean how objects work together, and the mediator deals with the work of objects working together, rather than “working for each object.”

The last sentence “can independently change their interaction” refers to the way objects interact with each other is not static, such as an input box component, just implements its own input function, regardless of how it interacts with the outside world. It can be embedded in the form as part of a form item, or it can be wrapped with a symbolic suffix to become a special amount input box.

chart

  • Mediator: An interface for defining communication apis.
  • ConcreteMediator: ConcreteMediator, inheriting Mediator, coordinating various objects.
  • Colleague: Colleagues, such as input boxes and text boxes mentioned earlier, only need to know that they are intermediaries.

The code example

The following example is written in typescript.

const memberA = new Member('art')
const memberB = new Member('process')

const picture = memberA.draw() // Draw the picture
const product = memberB.code(picture) // The program follows the art drawing to make products
Copy the code

In this case, the program and art are combined, and neither needs to know about the other. If products and test work are introduced later, there is no need to do complex correlation between them, but only need to add corresponding coordination logic in the intermediary.

disadvantages

While the mediator pattern is good, overuse can make the mediator logic very complex.

It is often said that the number of people directly managed by the manager should not exceed 20, because the coordination itself is also very energy consuming. If there are too many objects managed by an intermediary node, it may be difficult for the intermediary to maintain and even cause bugs.

The other is not to over-decouple, when two objects themselves can form a dependency, using the mediator pattern to force them to decouple will only bring a heavier burden of understanding.

conclusion

The mediator pattern may be appropriate when there are many system objects and their relationships are complex, and cross-references are prone to confusion.

The mediator pattern also conforms to Demeter’s law, which allows each object to know as little as possible, which is useful for large programs.

The discussion address is: Intensive reading of Design Pattern-Mediator Mode · Issue #299 · DT-fe /weekly

If you’d like to participate in the discussion, pleaseClick here to, with a new theme every week, released on weekends or Mondays. Front end Intensive Reading – Helps you filter the right content.

Pay attention to the front end of intensive reading wechat public account

Copyright Notice: Freely reproduced – Non-commercial – Non-derivative – Remain signed (Creative Commons 3.0 License)