(8) Intermediary mode

definition: encapsulates a series of object interactions with a mediator object, which causes the objects to be loosely coupled and can independently change the interaction between them without displaying the interaction of the objects.

Type: behavior class mode

Class Diagram:

The structure of the mediator pattern

The mediator pattern, also known as the mediator pattern, is divided into 3 parts from the class diagram:

L Abstract Mediator: defines the interface of the colleague class object to the Mediator object, and is used for communication between each colleague class. Typically includes one or several abstract event methods, and is implemented by subclasses.

L Mediator Implementation class: inherits from an abstract intermediary, implementing an event method defined in an abstract mediator. Receives a message from a colleague class and then affects other concurrent classes through the message.

L Colleague Class: if an object affects other objects and is also affected by other objects, these two objects are called colleague classes. In the class diagram, the colleague class has only one, this is actually the omission of reality, in the actual application, the colleague class generally consists of many, they influence each other and depend on each other. The more co-workers, the more complex the relationship. Also, a colleague class can be represented as a set of implementations that inherit the same abstract class. in the Mediator mode, the peer class must pass through the mediator to deliver the message.

Why to use the mediator mode

In general, the relationship between colleague classes is more complex, and when multiple colleague classes are interrelated, their relationship is presented as a complex network structure, an overly-coupled architecture that is not conducive to the reuse of classes and is not stable. For example, there are six colleague class objects, and if object 1 changes, then 4 objects will be affected. If object 2 changes, then 5 objects will be affected. In other words, the design of the direct association between colleague classes is not good.

If you introduce the mediator pattern, then the relationship between the colleague classes becomes a star structure, and you can see that the change of any one class only affects the class itself and the mediator, thus reducing the coupling of the system. A good design must not encapsulate all of the object relational processing logic in this class, but instead use a specialized class to manage behaviors that are not theirs.

We use an example to illustrate what a colleague class is: There are two classes A and B, each with a number in the class, and to ensure that the number in class B is always 100 times times the number in Class A. That is, when you modify the number of Class A, multiply this number by 100 and assign it to Class B, while modifying Class B assigns the number divided by 100 to Class A. Class A b affects each other and is called a colleague class. The code is as follows:

Abstract class Abstractcolleague {

Protectedint number;

Publicint GetNumber () {

Returnnumber;

}

publicvoid setnumber (int number) {

this.number= number;

}

Abstract method, modifying the associated object at the same time when modifying a number

publicabstract void Setnumber (int number, Abstractcolleague coll);

}

Class Colleaguea extends abstractcolleague{

publicvoid setnumber (int number, Abstractcolleague coll) {

this.number= number;

Coll.setnumber (number*100);

}

}

Class Colleagueb extends abstractcolleague{

publicvoid setnumber (int number, Abstractcolleague coll) {

this.number= number;

Coll.setnumber (number/100);

}

}

public class Client {

publicstatic void Main (string[] args) {

Abstractcolleaguecolla = new Colleaguea ();

ABSTRACTCOLLEAGUECOLLB = new Colleagueb ();

System.out.println ("========== set a influence b==========");

Colla.setnumber (1288,COLLB);

SYSTEM.OUT.PRINTLN ("Number Value of CollA:" +colla.getnumber ());

SYSTEM.OUT.PRINTLN ("Number Value of COLLB:" +collb.getnumber ());

System.out.println ("========== set B affects a==========");

Collb.setnumber (87635,colla);

SYSTEM.OUT.PRINTLN ("Number Value of COLLB:" +collb.getnumber ());

SYSTEM.OUT.PRINTLN ("Number Value of CollA:" +colla.getnumber ());

}

}

In the above code, Class A B has a relationship through a direct association, and if we want to use the mediator pattern, the Class A Class B is not directly related, they must be through a mediator to achieve the purpose of the association.

Abstract class Abstractcolleague {

Protectedint number;

Publicint GetNumber () {

Returnnumber;

}

publicvoid setnumber (int number) {

this.number= number;

}

Note that the argument here is no longer a colleague class, but a mediator

publicabstract void Setnumber (int number, abstractmediator am);

}

Class Colleaguea extends abstractcolleague{

publicvoid setnumber (int number, abstractmediator am) {

this.number= number;

Am. AAFFECTB ();

}

}

Class Colleagueb extends abstractcolleague{

@Override

publicvoid setnumber (int number, abstractmediator am) {

this.number= number;

Am. Baffecta ();

}

}

Abstract class Abstractmediator {

Protectedabstractcolleague A;

Protectedabstractcolleague B;

Publicabstractmediator (Abstractcolleague A, Abstractcolleague b) {

A= A;

B= b;

}

publicabstract void Aaffectb ();

publicabstract void Baffecta ();

}

Class Mediator extends Abstractmediator {

Publicmediator (Abstractcolleague A, Abstractcolleague b) {

Super (A, b);

}

Dealing with the effect of A on B

Publicvoid AAFFECTB () {

Intnumber = A.getnumber ();

B.setnumber (number*100);

}

Dealing with the effect of B on a

Publicvoid Baffecta () {

Intnumber = B.getnumber ();

A.setnumber (number/100);

}

}

public class Client {

publicstatic void Main (string[] args) {

Abstractcolleaguecolla = new Colleaguea ();

ABSTRACTCOLLEAGUECOLLB = new Colleagueb ();

Abstractmediatoram = new Mediator (CollA, COLLB);

System.out.println ("========== by setting a influence b==========");

Colla.setnumber (1000,AM);

SYSTEM.OUT.PRINTLN (the number value of the CollA is: "+colla.getnumber ());

System.out.println ("The number of the COLLB is 10 times times the value of a:" +collb.getnumber ());

System.out.println ("========== by setting B influence a==========");

Collb.setnumber (1000,AM);

SYSTEM.OUT.PRINTLN (the number value of the COLLB is: "+collb.getnumber ());

System.out.println ("CollA is 0.1 times times the number of B:" +colla.getnumber ());

}

}

Although the code is relatively long, but it is relatively easy to understand, in fact, the original processing object relationship code to a mediation class, through this intermediary class to deal with the relationship between objects.

Advantages of the broker model

The proper use of the mediator pattern avoids over-coupling between colleague classes, making it possible to use the peer classes relatively independently.

Using the mediator pattern, you can transform a one-to-many association between objects into one-to-one associations, making relationships between objects easy to understand and maintain.

Using the mediator pattern, you can abstract the behavior and collaboration of objects, and be able to manipulate the interaction between objects more flexibly.

Applicable scenarios

In object-oriented programming, a class is bound to have dependencies on other classes, and completely independent classes are meaningless. It is also quite common for a class to rely on multiple classes at the same time, since there is a case that a one-to-many dependency has its rationality, and proper use of the mediator pattern can make the original messy object relationship clear, but if abused, it can have a reverse effect. In general, the use of the mediator pattern is only considered if the relationship between the peer class is a network structure. The mesh structure can be transformed into a star-like structure, making the relationship between colleague classes clearer.

The intermediary mode is a kind of more commonly used pattern, and it is also a more easily abused mode. For most cases, the relationship between colleague classes is not complex to a cluttered network structure, so in most cases it is possible to encapsulate the dependencies between objects within a colleague class, and there is no need to introduce a mediator pattern. Abusing the broker model will only make things more complicated.

(8) Intermediary mode