The mediator mode of Java design pattern detailed _java

In Dr Shanhong's "Java and Schema" book, this describes the Mediator (mediator) pattern:

The mediator pattern is the behavior pattern of the object. The mediator pattern wraps a series of object interactions so that these objects do not have to be clearly referenced to each other. So that they can be loosely coupled. When the interaction between some objects in these objects changes, it does not immediately affect the interaction between some of the other objects. Thus ensuring that these interactions can vary independently from one another.

Why do we need mediators?

As the following illustration shows, there are a large number of objects in this diagram, which affect other objects and are affected by other objects, so they are often called colleague (colleague) objects. These coworker objects form the system's behavior through each other's interactions. As you can see from the diagram, almost every object needs to interact with other objects, and this interaction is represented by the direct coupling of one object with another. This is an overly coupled system.

By introducing the Mediator object (mediator), the network structure of the system can be transformed into an intermediary-centric star structure, as shown in the following figure. In this star structure, the coworker object no longer interacts with another object by direct contact, and instead interacts with another object through the Mediator object. The existence of mediator object ensures the stability of object structure, that is, the structure of the system does not cause a lot of modification because of the introduction of new object.

A good object-oriented design can increase the collaboration between objects (collaboration) and reduce coupling (couping). A thoughtful design breaks down a system into a group of interacting colleagues, and then gives each co-worker a unique responsibility to configure their collaboration appropriately so that they can work together.

If there is no motherboard

We all know that the interaction between the various parts of the computer, mainly through the motherboard to complete. If the computer does not have a motherboard, then each component must interact with each other to transmit data to each other. And because of the different parts of the interface, interaction between each other, you must also transform the data interface to match.

Fortunately, with the motherboard, the various parts of the interaction through the motherboard to complete, each of the accessories only need to interact with the motherboard, and the motherboard know how to deal with all the accessories, this is much simpler.

The structure of the mediator model

The schematic class diagram of the mediator pattern is shown below:

The mediator model includes the following roles:

Abstract Mediator (mediator) role: Defines the interface of a coworker object to a mediator object, where the primary method is one (or more) event methods.
The specific mediator (Concretemediator) role: Implements the event method declared by the abstract mediator. The specific mediator is aware of all the specific colleague classes and is responsible for the specific coordination of the interaction between the colleagues.
Abstract colleague Class (colleague) role: Defines the interface of a mediator to a coworker's object. Colleague objects only know the mediator and do not know the rest of the colleagues.
Specific colleague Class (Concretecolleague) role: All the specific coworker classes inherit from the abstract colleague class. Implement your business, communicate with the mediator when you need to communicate with other colleagues, and the mediator will be responsible for interacting with other colleagues.

Source

Abstract Mediator Class

Copy Code code as follows:

Public interface Mediator {
/**
* Work with co-workers to inform the mediator when they change their ways
* Let the mediator be responsible for the corresponding interaction with other colleagues ' objects
*/
public void changed (colleague C);
}

Specific Mediator class

Copy Code code as follows:

Public class Concretemediator implements mediator {
Hold and maintain colleague a
Private Concretecolleaguea Colleaguea;
Hold and maintain colleague B
Private Concretecolleagueb Colleagueb;

public void Setcolleaguea (Concretecolleaguea Colleaguea) {
This.colleaguea = Colleaguea;
}

public void Setcolleagueb (Concretecolleagueb colleagueb) {
This.colleagueb = Colleagueb;
}

@Override
public void changed (colleague C) {
/**
* One colleague class has changed, and usually needs to interact with other colleagues
* Coordinate the corresponding colleague object to achieve collaborative behavior
*/
}

}

Abstract Colleague Class

Copy Code code as follows:

Public abstract class Colleague {
Hold a Mediator object
Private mediator mediator;
/**
* Constructor
*/
Public colleague (mediator mediator) {
This.mediator = Mediator;
}
/**
* Get current coworker class corresponding Mediator object
*/
Public Mediator Getmediator () {
return mediator;
}

}

Specific colleague Class

Copy Code code as follows:

Public class Concretecolleaguea extends colleague {

Public Concretecolleaguea (mediator mediator) {
Super (mediator);
}
/**
* Schematic method, perform certain actions
*/
public void operation () {
Notifies the mediator when it is necessary to communicate with other colleagues
Getmediator (). Changed (this);
}
}

Copy Code code as follows:

Public class Concretecolleagueb extends colleague {

Public Concretecolleagueb (mediator mediator) {
Super (mediator);
}
/**
* Schematic method, perform certain actions
*/
public void operation () {
Notifies the mediator when it is necessary to communicate with other colleagues
Getmediator (). Changed (this);
}
}

Use the computer to watch movies

In our daily life, we often use computers to see movies, describe the process, and simplify and assume that there are interactive processes like the following:

(1) First is the optical drive to read the data on the disc, and then tell the motherboard, its status changed.

(2) The motherboard to obtain the optical drive data, the data to the CPU for analysis and processing.

(3) After the CPU processing, the data into the video data and audio data, notify the motherboard, it finished processing.

(4) The motherboard to get the CPU processing data, the data to the video card and sound card, to show the video and sound.

To use the mediator pattern to implement the example, it is necessary to distinguish between the coworker object and the Mediator object. Obviously, the motherboard is the mediator, and the optical drive, sound card, CPU, graphics and other accessories, are as colleagues object.

Source

Abstract Colleague Class

Copy Code code as follows:

Public abstract class Colleague {
Hold a Mediator object
Private mediator mediator;
/**
* Constructor
*/
Public colleague (mediator mediator) {
This.mediator = Mediator;
}
/**
* Get current coworker class corresponding Mediator object
*/
Public Mediator Getmediator () {
return mediator;
}
}

Colleague Class-Optical drive

Copy Code code as follows:

public class Cddriver extends colleague{
The data that the optical drive reads out
Private String data = "";
/**
* Constructor
*/
Public Cddriver (mediator mediator) {
Super (mediator);
}
/**
* Get the data read from the CD
*/
Public String GetData () {
return data;
}
/**
* Read CD
*/
public void Readcd () {
Before the comma is the video display data, after the comma is the sound
This.data = "One Piece, the Sea Thief King I when set";
Notify the motherboard that your state has changed
Getmediator (). Changed (this);
}
}

Colleague Class--cpu

Copy Code code as follows:

Public class CPU extends colleague {
Decomposition of video data
Private String Videodata = "";
The sound data that is broken up
Private String Sounddata = "";
/**
* Constructor
*/
Public CPU (mediator mediator) {
Super (mediator);
}
/**
* Get the decomposed video data
*/
Public String Getvideodata () {
return videodata;
}
/**
* Get the decomposed sound data
*/
Public String Getsounddata () {
return sounddata;
}
/**
* Processing data, dividing the data into audio and video data
*/
public void Executedata (String data) {
Break down data, front is video data, followed by audio data
string[] Array = Data.split (",");
This.videodata = array[0];
This.sounddata = array[1];
Notifies the motherboard that the CPU completes its work
Getmediator (). Changed (this);
}

}

Colleague class--graphics card

Copy Code code as follows:

Public class Videocard extends colleague {
/**
* Constructor
*/
Public Videocard (mediator mediator) {
Super (mediator);
}
/**
* Display video data
*/
public void ShowData (String data) {
System.out.println ("What you are watching is:" + data);
}
}

Colleague class--sound card

Copy Code code as follows:

Public class Soundcard extends colleague {
/**
* Constructor
*/
Public soundcard (mediator mediator) {
Super (mediator);
}
/**
* Sound with audio data
*/
public void Sounddata (String data) {
System.out.println ("VoiceOver:" + data);
}
}

Abstract Mediator Class

Copy Code code as follows:

Public interface Mediator {
/**
* Work with co-workers to inform the mediator when they change their ways
* Let the mediator be responsible for the corresponding interaction with other colleagues ' objects
*/
public void changed (colleague C);
}

Specific Mediator class

Copy Code code as follows:

Public class Mainboard implements mediator {
Need to know the colleague class to interact with--optical drive class
Private Cddriver cddriver = null;
Need to know colleague class--cpu class to interact with
Private CPU CPU = NULL;
Need to know the colleague class to interact--video card class
Private Videocard videocard = null;
Need to know the colleague class to interact--sound card class
Private soundcard soundcard = null;

public void Setcddriver (Cddriver cddriver) {
This.cddriver = Cddriver;
}

public void Setcpu (CPU CPU) {
THIS.CPU = CPU;
}

public void Setvideocard (Videocard videocard) {
This.videocard = Videocard;
}

public void Setsoundcard (Soundcard soundcard) {
This.soundcard = soundcard;
}

@Override
public void changed (colleague C) {
if (c instanceof cddriver) {
Indicates that the optical drive reads data
This.opecddriverreaddata ((Cddriver) c);
}else if (c instanceof CPU) {
THIS.OPECPU ((CPU) c);
}
}
/**
* Processing the optical drive after reading data with other objects to interact with
*/
private void Opecddriverreaddata (Cddriver CD) {
Get the data read from the optical drive first
String data = Cd.getdata ();
Pass this data to the CPU for processing
Cpu.executedata (data);
}
/**
* Interact with other objects after the CPU has finished processing data
*/
private void Opecpu (CPU CPU) {
Get CPU-processed data first
String videodata = Cpu.getvideodata ();
String sounddata = Cpu.getsounddata ();
Pass this data to the graphics card and the sound card.
Videocard.showdata (Videodata);
Soundcard.sounddata (Sounddata);
}
}

Client class

Copy Code code as follows:

public class Client {

public static void Main (string[] args) {
Create Mediator-Motherboard
mainboard Mediator = new mainboard ();
Create a colleague Class
Cddriver cd = new Cddriver (mediator);
CPU CPU = new CPU (mediator);
Videocard VC = new Videocard (mediator);
Soundcard sc = new soundcard (mediator);
Let the mediator know all of his colleagues
Mediator.setcddriver (CD);
MEDIATOR.SETCPU (CPU);
Mediator.setvideocard (VC);
Mediator.setsoundcard (SC);
Start to see the film, put the CD into the CD drive, CD drive start reading disk
CD.READCD ();

}

}

The results of the operation are as follows:

The advantages of the mediator model
loosely coupled

The mediator pattern can be loosely coupled between peer objects by encapsulating the interaction of multiple peer objects into the Mediator object, which is essentially complementary. As a result, colleagues can change and reuse independently, instead of "holding one place" as before.

Centralized control interaction

The interaction of multiple peer objects, encapsulated within the mediator's object, is centrally managed so that when these interactions change, only the mediator object needs to be modified, and, of course, if the system is already done, the Mediator object is extended, and each colleague class does not need to be modified.

Many to many to become a pair of many

In the absence of mediator mode, the relationship between coworker objects is often many-to-many, and after the introduction of the Mediator object, the relationship between the mediator and the coworker usually becomes a two-way one-to-many, which makes the object's relationship easier to understand and implement.

Disadvantages of the mediator model

One potential drawback of the mediator model is excessive centralization. If the interaction of a coworker's object is very numerous and complex, when all of these complexities are concentrated on the mediator, the Mediator object becomes complex and difficult to manage and maintain.