Design Pattern (22)-intermediary pattern (behavior pattern)

1. Introduction (Brief Introduction)

Define an intermediary object to encapsulate the interaction between objects of a series. The intermediary allows each object to reference each other without being displayed, so that the coupling is loose and the interaction between them can be changed independently.

Example: when I was in junior high school, I didn't have QQ. It was very difficult to get together after graduation. I know classmates A and B. You know me ......, This is probably the following scenario:

Before using QQ:

If the number of students increases, it will become a mesh structure. In the past, dividing a system into some objects can enhance reusability. However, there is a large number of connections between these implementations, and the coupling is extremely high. This is not conducive to reuse. At the same time, the flexibility of the system is greatly reduced, making it difficult to expand the system. If a new student is transferred, there will be more changes.

After using QQ: you can design this system in another way, such as creating a star structure:

Let's take a look at the difference between this "star structure" and "mesh structure". Obviously, using a star structure can avoid problems with the above mesh structure, in fact, QQ refers to the intermediary, so that every student object does not have to be coupled, and students need to communicate with each other through a QQ group. The transformation from the original mesh structure to the star structure is a good way to understand the intermediary mode.

Ii. Analysis)

Abstract mediator: defines the interface between a colleague Class Object and an intermediary object for communication between different colleagues' classes. It generally includes one or several abstract event methods, which are implemented by sub-classes.

Concretemediator. Understand and maintain its colleagues.

Abstract colleague class: defines colleague class interfaces and public methods of colleagues.

Concretecolleague: Implements methods in abstract colleagues' classes. At the same time, each class needs to know the intermediary object. Each specific colleague class only needs to understand its own behavior, rather than the situation of other colleagues' classes. When a colleague object needs to communicate with other colleagues, it communicates with its intermediary.

Iii. Case Analysis (example)

Namespace intermediary Mode
{

1. Client

 

 
Class program {static void main (string [] ARGs) {concretemediator M = new concretemediator (); required C1 = new concretecolleague1 (m); concretecolleague2 C2 = new concretecolleague2 (m ); m. colleague1 = C1; M. colleague2 = c2; c1.send ("Have you ever eaten? "); C2.send (" no, are you going to treat me? "); Console. Read ();}}
 

2. mediator class abstract intermediary object

 
Abstract class mediator {public abstract void send (string message, colleague );}
 

3. colleague abstract colleague class

Abstract class colleague {protected mediator; Public colleague (mediator) {This. mediator = mediator ;}}
 

4. Specific intermediary

 
Class concretemediator: mediator {private concretecolleague1 colleague1; private parameter colleague2; Public parameter colleague1 {set {colleague1 = value ;}} public parameter colleague2 {set {colleague2 = value ;}} public override void send (string message, colleague) {If (colleague = colleague1) {colleague2.y y (Message);} else {colleague1.notify (Message );}}}
 

5. Specific object classes

Class concretecolleague1: colleague {public concretecolleague1 (mediator): Base (mediator) {} public void send (string message) {mediator. send (message, this);} public void receivy (string message) {console. writeline ("colleague 1 get information:" + message) ;}} class concretecolleague2: colleague {public concretecolleague2 (mediator): Base (mediator) {} public void send (string message) {mediator. send (message, this);} public void receivy (string message) {console. writeline ("colleague 2 get information:" + message );}}}
 

 

4. What to solve)

1) the objects in the system have complex reference relationships, resulting in chaotic and difficult to understand the dependency structure.

2) A group of objects communicate in a well-defined but complex manner. The resulting dependency structure is confusing and hard to understand.

3) an object references many other objects and communicates directly with these objects, making it difficult to reuse the object.

4) You want to use an intermediate class to encapsulate the behavior of multiple classes without generating too many child classes. You can introduce the intermediary class to define the public behavior of object interaction in the intermediary. If you need to change the behavior, you can add a new intermediary class.

V. Advantages and Disadvantages)

Advantages:

1) Reduce subclass generation: mediator aggregates the behavior originally distributed among multiple objects. To change these actions, you only need to generate a subclass of mediator. In this way, various colleags can be reused.

2) simplify the design and implementation of various colleagues' classes: It decouples colleagues' classes, and mediator facilitates loose coupling between colleagues' classes. you can independently change and reuse the collection class and mediator class.

3) It simplifies the Object Protocol: the one-to-many interaction between the mediator and colleague replaces the many-to-many interaction. One-to-multiple relationships are easier to understand, maintain, and expand.

4) It abstracts how objects collaborate and uses mediation as an independent concept and encapsulates it in an object, this allows you to focus on the interaction between objects. This helps to figure out how objects interact in a system.

5) It enables centralized mediation control to change the complexity of interaction into the complexity of the intermediary.

Disadvantages:

Because the intermediary encapsulates the protocol, that is, contains the interaction details between colleagues in a specific intermediary class, the specific intermediary class may be very complicated, this may make the intermediary itself a giant that is difficult to maintain.

6. Extended)

1) a typical application of the dimit rule: In the intermediary mode, by creating an intermediary object, the number of other objects referenced by the objects in the system is minimized, so that the interaction between an object and its colleagues is replaced by the interaction between the object and the intermediary object. Therefore, the intermediary model is a typical application of the dimit law.

2) by introducing the intermediary object, the system's mesh structure can be changed to a star structure centered on the intermediary, and the intermediary undertakes the transit and coordination roles. The intermediary class is the core of the intermediary mode. It controls and coordinates the entire system, simplifies interaction between objects, and further controls interaction between objects.

7. Link)

1) Appearance mode. Facade differs from the intermediary in that it abstracts an object subsystem and provides a convenient interface. Its Protocol is unidirectional, that is, the facade object initiates a request to this sub-system class, but the opposite is not. On the contrary, mediator provides collaborative behaviors that are not supported or not supported by each colleague object, and the protocol is multi-direction.

2) colleags can communicate with mediator in observers mode.

Summary)

In object-oriented programming, a class is bound to be dependent on other classes, and completely independent classes are meaningless. It is also quite common that a class depends on multiple classes at the same time. In this case, one-to-many dependencies are rational, the proper use of the intermediary mode can clear the original messy object relationship, but abuse may result in reverse effects. Generally, the intermediary mode is considered only when the relationship between colleague classes is in a mesh structure. The mesh structure can be changed to a star structure, so that the relationship between colleagues and classes becomes clearer.

Intermediary mode is a common mode and a mode that is easy to abuse. In most cases, the relationships between colleague classes are not complex to messy mesh structures. Therefore, in most cases, the inter-object dependency can be encapsulated inside the colleague classes, there is no need to introduce the intermediary mode. Misuse of the intermediary model only makes things more complicated.