Design Pattern-Mediator Pattern)

Design Pattern-Mediator Pattern)

 

I. Introduction  The intermediary is no stranger in real life, the housing intermediary in full Street, and the intermediary abroad ....... They exist because they can bring some convenience to our lives: renting a house or buying a house doesn't need to go around in different communities; you don't have to worry about studying abroad. The intermediary model also plays a similar role in programming. Ii. Definition and Structure Gof defines the intermediary mode to encapsulate a series of object interactions with an intermediary object. The intermediary makes it unnecessary for objects to explicitly reference each other, so that the coupling is loose and the interaction between objects can be changed independently. To put it simply, remove two objects directly referenced or dependent, and add an "intermediary" object in the middle so that the objects at both ends can be referenced or depended on by the "intermediary" object respectively. Of course, not all objects need to be added to the "intermediary" object. If the relationships between objects are clear at a glance, the addition of intermediary objects is "superfluous ". Let's take a look at the components of the intermediary mode. 1) Abstract intermediary role: the abstract intermediary role defines a unified interface for communication between the roles of colleagues. 2) Concrete mediator role: the intermediary role coordinates the roles of colleagues to implement collaboration. Therefore, it needs to know and reference the roles of colleagues. 3) colleagues' roles: each colleague role knows the corresponding intermediary role and must collaborate with other colleagues' roles when communicating with other colleagues' roles. Class diagrams from design patterns: Because the actions of the intermediary and the data to be used are closely related to the specific business, it is unrealistic to abstract the intermediary role to provide an interface that facilitates the use of many objects. Therefore, the abstract intermediary role often does not exist, or it is only a tag interface. If you are lucky enough to extract the abstract intermediary role with behaviors, I think the choice of a colleague role for a specific intermediary role is also an application of strategy. "Just right, too late ". The most suitable system is the best. III. Further Discussion Do you still remember which layer of MVC is widely used? Model, view, and control/mediator ). The control layer is the intermediary between the presentation layer and the model layer. In general, MVC is also an application of the intermediary model in the framework design. Because the intermediary mode is loose in definition, the structure is very similar to the observer mode and command mode. The purpose of the application is similar to the structure mode "Facade mode. In terms of structure, the intermediary mode and the observer mode and the command mode both add Intermediate objects-only the intermediary removes the behavior direction of the latter two. Therefore, the intermediary's application can be written in the following example. However, the observer and command in the Observer mode and command mode are all known to the customer. The customer specifies the observer and command application; most intermediary roles are transparent to customer programs. Of course, the reason for this difference is that they have different purposes. From the perspective of purpose, the intermediary mode has nothing to do with the observer mode and command mode, but it is somewhat similar to the facade mode mentioned above. However, the facade mode is between the customer program and the subsystem, while the intermediary mode is between the subsystem and the subsystem. This is also doomed to their great difference: the facade mode is to extract the original complex logic to a unified interface, simplifying the customer's use of the logic. It is perceived by customers, while the original complex logic is hidden. The addition of the intermediary mode does not change the customer's original usage habits. It is hidden behind the original logic, making the code logic more clear and available. Previously, we wrote down the characteristics of the intermediary model. Here we will summarize. The biggest benefit of using the intermediary mode is to decouple the colleagues' roles. This brings about a series of system structure improvements: improved the readability of the original system and simplified the communication protocol of the original system-changed the original many-to-many to improve code reusability ...... However, the intermediary role has too many responsibilities, and all related colleagues' objects must be controlled by it. This reminds me of the simple factory model, but due to the special nature of the intermediary model-closely related to the business logic, it is not possible to adopt a solution similar to the factory method model. Therefore, we recommend that you control the size of the intermediary role when using the intermediary mode. We have discussed so many features about the intermediary model. The time to use the intermediary mode can be summarized: A group of objects communicate in a well-defined but complex manner, resulting in chaotic dependencies and difficulty in reusing objects. Iv. Summary The intermediary mode is easy to apply in the system and misuse in the system. When the system has a complex multi-to-many interaction object group, do not rush to use the intermediary mode, but first reflect on whether your system is designed properly. The mediator mode defines how an object encapsulates a series of objects to interact with each other, so that objects do not need to be explicitly referenced to each other, so that their coupling is more loose, it also allows us to independently change the interaction between multiple objects. The structure is as follows: The example in a chat room shows that a chat room can contain many members who can join different discussion groups. The chat room is an intermediary, and members of the chat room can send messages through the chat room. The structure is as follows: Implementation Code: // ichatroom. h Class user; Class ichatroom { Public: Ichatroom (); Virtual ~ Ichatroom (); Virtual void register (User *) = 0; Virtual void send (char * pfrom, char * PTO, char * PMSG) = 0; }; // Ichatroom. cpp # Include "stdafx. H" # Include "ichatroom. H" Ichatroom: ichatroom () { } Ichatroom ::~ Ichatroom () { } // Chatroom. h # Include "ichatroom. H" # Include <map> Using namespace STD; Class chatroom: Public ichatroom { Public: Chatroom (); Virtual ~ Chatroom (); Void register (User *); Void send (char * pfrom, char * PTO, char * PMSG ); PRIVATE: Map <char *, user *> m_mapusers; }; // Chatroom. cpp # Include "stdafx. H" # Include "chatroom. H" # Include "user. H" Chatroom: chatroom () { } Chatroom ::~ Chatroom () { } Void chatroom: Register (User * puser) { Char * A = puser-> m_pname; If (m_mapusers [puser-> m_pname] = NULL) { M_mapusers [puser-> m_pname] = puser; } Puser-> setchatroom (this ); } Void chatroom: Send (char * pfrom, char * PTO, char * PMSG) { User * puserto = (User *) m_mapusers [PTO]; If (puserto! = NULL) { Puserto-> receive (pfrom, PMSG ); } } // User. h Class chatroom; Class user { Public: User (char *); Virtual ~ User (); Void send (char * PTO, char * PMSG ); Virtual void receive (char * pfrom, char * PMSG ); Void setchatroom (chatroom *); Friend class chatroom; PRIVATE: Char * m_pname; Chatroom * m_pchatroom; }; // User. cpp # Include "stdafx. H" # Include "user. H" # Include "chatroom. H" # Include <iostream> Using namespace STD; User: user (char * pname) { M_pname = pname; } User ::~ User () { If (m_pchatroom! = NULL) { Delete m_pchatroom; M_pchatroom = NULL; } } Void User: Send (char * PTO, char * PMSG) { M_pchatroom-> send (m_pname, PTO, PMSG ); } Void User: setchatroom (chatroom * pchatroom) { M_pchatroom = pchatroom; } Void User: receive (char * pfrom, char * PMSG) { Cout <pfrom <"to" <this-> m_pname <":" <PMSG <Endl; } // Useringroupa. h # Include "user. H" Class useringroupa: public user { Public: Useringroupa (char *); Virtual ~ Useringroupa (); Virtual void receive (char * pfrom, char * PMSG ); }; // Useringroupa. cpp # Include "stdafx. H" # Include "useringroupa. H" # Include <iostream> Using namespace STD; Useringroupa: useringroupa (char * pname): user (pname) { } Useringroupa ::~ Useringroupa () { } Void useringroupa: receive (char * pfrom, char * PMSG) { Cout <"group A members receive a message -"; User: receive (pfrom, PMSG ); } // Useringroupb. h # Include "user. H" Class useringroupb: public user { Public: Useringroupb (char *); Virtual ~ Useringroupb (); Virtual void receive (char * pfrom, char * PMSG ); }; // Useringroupb. cpp # Include "stdafx. H" # Include "useringroupb. H" # Include <iostream> Using namespace STD; Useringroupb: useringroupb (char * pname): user (pname) { } Useringroupb ::~ Useringroupb () { } Void useringroupb: receive (char * pfrom, char * PMSG) { Cout <"group B members receive a message -"; User: receive (pfrom, PMSG ); } // Main. cpp # Include "stdafx. H" # Include "chatroom. H" # Include "useringroupa. H" # Include "useringroupb. H" Int main (INT argc, char * argv []) { Chatroom * pchatroom = new chatroom; User * pusera = new useringroupa ("usera "); User * puserb = new useringroupa ("userb "); User * puserc = new useringroupb ("userc "); Pchatroom-> Register (pusera ); Pchatroom-> Register (puserb ); Pchatroom-> Register (puserc ); Pusera-> send ("userb", "Hello, userb "); Puserb-> send ("userc", "Hello, userc "); Puserc-> send ("usera", "Hello, usera "); Return 0; }