The design pattern I understand (C ++ implementation) -- Mediator Pattern)

Overview:

Suppose we develop an image processing software, which must include many related functions, such as cutting, rotating, filters, and beautification. The objects to be processed by these functions are fixed, that is the image we display. However, we cannot list all functions on one tab. This is convenient but not beautiful. This is what we can do: use an intermediary class to initialize and execute all functions. When we need a function, we can directly call the intermediary class.

The intermediary mode defines an intermediary object to encapsulate the interaction between objects in 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.

Class charts and Instances

MediatorClass: An abstract intermediary that defines interfaces for interaction between colleague objects.

ConcretemediatorClass: A specific intermediary object that implements methods in an abstract class. This specific intermediary object needs to know all the specific colleagues' classes, receive messages from specific colleagues, and send commands to specific colleagues' objects.

CollegouClass:Abstract colleague class.

ConcretecolleagueClass:A specific colleague class is used to abstract methods in the colleague class. 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.

# Include <iostream> # include <vector> # include <string> using namespace STD; Class colleage {PRIVATE: string name; string content; public: colleage (string n = ""): Name (n) {}; void set_name (string name) {This-> name = Name;} string get_name () {return this-> name ;} void set_content (string content) {This-> content = content;} string get_content () {If (content. size ()! = 0) return content; else return "Copy that" ;}virtual void talk () {};}; class monitor: Public colleage {public: Monitor (string n = ""): colleage (n) {}; virtual void talk () {cout <"banner" <get_name () <"said:" <get_content () <Endl ;}; class secretary: Public colleage {public: Secretary (string n = ""): colleage (n) {}; virtual void talk () {cout <"" <get_name () <"said:" <get_content () <Endl ;}}; class studenta: Public Co Lleage {public: studenta (string n = ""): colleage (n) {}; virtual void talk () {cout <"student a" <get_name () <"Description:" <get_content () <Endl ;}}; class studentb: Public colleage {public: studentb (string n = ""): colleage (N) {}; virtual void talk () {cout <"Student B" <get_name () <"says:" <get_content () <Endl ;}}; class mediator {public: vector <colleage *> studentlist; virtual void add_student (colleage * student) {studentlist. push_bac K (student) ;}; virtual void y (colleage * student) {};}; class qqmediator: public mediator {public: Virtual void notify (colleage * student) {student-> talk (); For (INT I = 0; I <studentlist. size (); ++ I) {If (student! = Studentlist [I]) {studentlist [I]-> talk () ;}};}; int main () {qqmediator QQ; monitor * studentmonitor = new monitor ("Foxx"); Secretary * studentsecretary = new secretary ("Tc"); studenta * studenta = new studenta ("Jack "); studentb * studentb = new studentb ("Frank"); QQ. add_student (studentsecretary); QQ. add_student (studenta); QQ. add_student (studentb); studentmonitor-> set_content ("holiday starts tomorrow! "); QQ. Y (studentmonitor); Return 0 ;}

Applicability:

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

2. An object references many other objects and communicates directly with these objects, making it difficult to reuse the object.

3. You do not want to generate too many child classes if you want to customize a behavior distributed across multiple classes.

Advantages and disadvantages:

Advantages of using the intermediary mode:

1. The coupling between system objects is reduced, making objects easy to be reused independently.

2. Improve system flexibility and make the system easy to expand and maintain.

Disadvantages of using the intermediary mode:

Because our "intermediary" bears a lot of responsibilities, once this intermediary object encounters a problem, the entire system will be greatly affected.

Lcl_data was originally created in csdn. Net [http://blog.csdn.net/lcl_data/article/details/9529427]

For other design patterns, see:Design patterns I understand