[C + +] Mediator Pattern Reality

Recently in review design Pattern, long time useless have some forget, mainly is no opportunity to do development practice,

Today to review, do not know that my concept is not correct.

Mediator implements a man-in-the-middle processing mechanism that is suitable for application scenarios:

1) When multiple entities (or objects) interact with each other, the relationship between each other is diverse and complex,

2) or when an entity interacts with multiple entities at the same time. You want to reduce the amount of interactivity in one way.

Just like the video of the fruit chat, Meimei at the same time and multiple audience interaction, if everyone with different video software (QQ, SKYPE, the WEB), it must be very troublesome,

It's not easy to communicate between audiences,

So, if you can interact on the same platform that much better.

The design pattern structure of the middleman is as follows:

Mediator Abstract class is the middleman, is the interface that everyone interacts with each other.

The Concretemediator class is the implementation of mediator, which needs to recognize all colleage entities interacting with each other in order to achieve mutual interaction.

The colleage abstract class is the parent category for all entities that you want to interact with.

The Concretecolleage class is the practice of colleage, and every entity needs to know the middleman, but the entities don't need to know each other, just define their own behavior.

The following is a specific code for the man-in-the-middle mode

The main function of the code is to simulate three light bulbs, and when the user hand touches one of them, the other two lights switch simultaneously.

Use case:

A, B, c three bulb, initial full dark

(1) Hand touch B, then A, c turn bright

(2) Hand again touch A, then B turn bright, C turn dark

The final result is a bright, b bright, C dark

It is the hand that touches one, the other two change the state.

Of course, changing the state of the instruction can be imagined as the hand touched by the light bulb call the middleman, let the middleman to do touch the light bulb after the corresponding action,

Functional practice is wrapped in the middle human, no one else will know.

/////////////////////////////////////////////////////////////////////////////////////////////////////////////// ///////////////

On the code!

[CBulb.h] This is Colleage abstract class, then to do it as a bulb entity

#ifndef _cbulb_#define _cbulb_#include "CMediator.h" class Cmediator;class cbulb {public:cbulb (); Cbulb (char *, BOOL, cmediator*); ~cbulb (); void Showstatus (); void Changestatus (); void Off (); void Press (); Cmediator *med;char *name;bool status; Bulb lighting or not: {0, 1}}; #endif

[CBulbA.h] Bulb Class A, inherited the Colleage

#ifndef _cbulba_#define _cbulba_#include "CBulb.h" class Cbulba:public cbulb {Public:cbulba (); Cbulba (char *, BOOL, cmediator*); ~cbulba ();}; #endif

B and C bulbs are the same as a.

[CBulb.cpp] The content of Colleage class, say is abstract class actually not abstract ah, I should not write this

#include "CBulb.h" cbulb::cbulb () {}cbulb::cbulb (char *str, bool status, cmediator* med) {this->status=status;name= StrDup (str); this->med=med;} Cbulb::~cbulb () {}void cbulb::showstatus () {printf ("Bulb%s:%s\n", Name, status? ") True ":" false ");} void Cbulb::changestatus () {status=!status;} void Cbulb::off () {status=false;} void Cbulb::P ress () {med->changestatus (name);}

[CBulbA.cpp] Bulb Class A entity

#include <string.h> #include "CBulbA.h" Cbulba::cbulba () {}cbulba::cbulba (char *str, bool status, cmediator* med) { This->status=status;name=strdup (str); this->med=med;} Cbulba::~cbulba () {}

[Mediator.h] Middleman abstract class

#ifndef _cmediator_#define _cmediator_#include "CBulb.h" #include <vector>using namespace Std;class cbulb;class Cmediator {public:cmediator (); ~cmediator (); virtual void registbulb (cbulb*); virtual void changestatus (char*); vector <CBulb*> rulblist;}; #endif

[ConcreteMediator.h] The middle human practice

#include "CMediator.h" class Cconcretemediator:public Cmediator {Public:cconcretemediator (); ~cconcretemediator (); void Registbulb (cbulb*); void Changestatus (char*);};

[Mediator.cpp] Middleman abstract class content

#include "CMediator.h" Cmediator::cmediator () {}cmediator::~cmediator () {}void cmediator::registbulb (cbulb *bulb) {} void Cmediator::changestatus (char* name) {}

[ConcreteMediator.cpp] The middle human implementation content, which acts as the interface class, all colleage interactive functions are written in this area.

#include "CConcreteMediator.h" Cconcretemediator::cconcretemediator () {}cconcretemediator::~cconcretemediator () {} void Cconcretemediator::registbulb (Cbulb *bulb) {rulblist.push_back (bulb);} void Cconcretemediator::changestatus (char *name) {int i=0;if (strcmp (name, "A") ==0)//B & C Light change{for (i=0;i <rulblist.size (); i++) {if (strcmp (Rulblist[i]->name, "B") ==0) {rulblist[i]->changestatus ();} else if (strcmp (Rulblist[i]->name, "C") ==0) {rulblist[i]->changestatus ();}}} else if (strcmp (name, "B") ==0)//A & C Light change{for (I=0;i<rulblist.size (); i++) {if (strcmp (rulblist[i]-> Name, "A") ==0) {rulblist[i]->changestatus ();} else if (strcmp (Rulblist[i]->name, "C") ==0) {rulblist[i]->changestatus ();}}} else if (strcmp (name, "C") ==0)//A & B Light change{for (I=0;i<rulblist.size (); i++) {if (strcmp (rulblist[i]-> Name, "A") ==0) {rulblist[i]->changestatus ();} else if (strcmp (Rulblist[i]->name, "B") ==0) {rulblist[i]->changestatus ();}}} else if (strcmp (name, "1") ==0)//All Light off{for (I=0;i<rulblist.size (); i++) {Rulblist[i]->off ();}}} 

[Main.cpp] Main program

/* *this program with the "mediator Pattern" simulating light-changes for a set of multiple bulbs. *author:jordan Yeh *DATE:2015/04/23 * * #include <stdio.h> #include <stdlib.h> #include <conio.h># Include <windows.h> #include "CBulbA.h" #include "CBulbB.h" #include "CBulbC.h" #include "CConcreteMediator.h" void Main () {char input;//declare mediatorcconcretemediator med;/Let all colleage know the Mediatorcbulba Bulb_a=cbulba ("A", false, &med); CBULBB BULB_B=CBULBB ("B", false, &med); CBULBC BULB_C=CBULBC ("C", false, &med);//Let mediator know all colleagemed. Registbulb (&bulb_a); Med. Registbulb (&bulb_b); Med. Registbulb (&bulb_c); while (1) {System ("CLS"); Bulb_a.showstatus (); Bulb_b.showstatus (); Bulb_c.showstatus (); printf ("==select one bult to press==\n");p rintf ("(A) B & C Light change\n");p rintf ("(B) A & C Light change\n") ;p rintf ("(C) A & B Light change\n");p The Rintf ("(1) All light off\n");p rintf ("(2) Exit programe\n"); Input=getch (); SWItch (input) {case ' 1 ': Med. Changestatus ("1"); Break;case ' 2 ': Return;break;case ' a ': Case ' a ': bulb_a.press (); Break;case ' B ': case ' B ': bulb_b.press (); Break;case ' C ': Case ' C ': bulb_c.press (); break;default:continue;}} return;}

The code is not complicated, the only comment should be enough,

In short, it is a real man-in-the-middle, a lamp,

Then let the light bulb know the middleman, the middleman registers all the bulbs,

Then the light bulb can start interacting.

Originally want to all wrapped into a document, and later felt that the concept of categorization will be more clear, and so on.

[C + +] Mediator Pattern Reality