23 design modes (20) java intermediary mode and 23 design modes

23 design modes (20) java intermediary mode and 23 design modes

23 design patterns Article 20th: java intermediary Model

Definition: encapsulate a series of object interactions with an intermediary object. The intermediary makes the interaction between objects do not need to be displayed, so that coupling is loose and interaction between objects can be changed independently.

Type: behavior mode

Class diagram:

Intermediary mode structure

The intermediary mode is also called the mediator mode. From the class diagram, there are three parts:

Abstract intermediary: defines the interface between a colleague Class Object and an intermediary object for communication between different colleagues' classes. It generally includes one or several abstract event methods, which are implemented by sub-classes.

Intermediary implementation class: inherits from the abstract intermediary to implement the event methods defined in the abstract intermediary. Receive messages from one colleague class, and then affect other concurrent classes through messages.

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, there is only one colleague class, which is actually omitted in reality. In actual application, the colleague classes are generally composed of multiple, And they interact and depend on each other. The more colleagues, the more complex the relationship. In addition, colleagues' classes can also be represented as a group of implementations that inherit the same abstract class. In the intermediary mode, the colleague classes must pass through the intermediary to transmit messages.

Why the intermediary mode?

In general, the relationship between colleague classes is relatively complex. When multiple colleague classes are correlated, the relationship between them is displayed as a complex mesh structure, this is an over-coupling architecture, which is not conducive to the reuse and instability of classes. For example, there are six colleagues' class objects. If object 1 changes, four objects will be affected. If object 2 changes, five objects will be affected. That is to say, the design of Direct association between colleague classes is not good.

If the intermediary mode is introduced, the relationship between the colleague classes will be changed to a star structure. You can see that any change to the class will only affect the class itself and the intermediary, this reduces system coupling. A good design will certainly not encapsulate all the object link processing logic in this class, but use a dedicated class to manage those behaviors that do not belong to you.

Let's use an example to illustrate what A colleague class is: There are two classes A and B, each of which has A number, make sure that the number in Class B is always 100 times the number in Class. That is to say, when modifying the number of class A, multiply the number by 100 and assign it to class B. When modifying Class B, divide the number by 100 and assign it to Class. Class A and Class B affect each other, which is called A colleague class. The Code is as follows:

Abstract class maid {protected int number; public int getNumber () {return number;} public void setNumber (int number) {this. number = number;} // abstract method. When modifying a number, you can modify the public abstract void setNumber (int number, AbstractColleague coll) of the associated object );} class ColleagueA extends actcolleague {public void setNumber (int number, AbstractColleague coll) {this. number = number; coll. setNumber (number * 100);} class ColleagueB extends AbstractColleague {public void setNumber (int number, AbstractColleague coll) {this. number = number; coll. setNumber (number/100) ;}} public class Client {public static void main (String [] args) {AbstractColleague collA = new ColleagueA (); AbstractColleague collB = new ColleagueB (); system. out. println ("=========== set A impact B ==========="); collA. setNumber (1288, collB); System. out. println ("collA's number value:" + collA. getNumber (); System. out. println ("number value of collB:" + collB. getNumber (); System. out. println ("=========== Set B impact A ============="); collB. setNumber (87635, collA); System. out. println ("number value of collB:" + collB. getNumber (); System. out. println ("collA's number value:" + collA. getNumber ());}}

In the code above, Class a B has A direct association. If we want to use the intermediary mode, Class a B cannot be directly associated, they must be associated through an intermediary.

Abstract class maid {protected int number; public int getNumber () {return number;} public void setNumber (int number) {this. number = number;} // note that the parameter here is no longer a colleague class, but an intermediary public abstract void setNumber (int number, AbstractMediator am );} class ColleagueA extends actcolleague {public void setNumber (int number, AbstractMediator am) {this. number = number; am. aaffectB () ;}} class ColleagueB extends abstractcolleags {@ Override public void setNumber (int number, AbstractMediator am) {this. number = number; am. baffectA () ;}} abstract class AbstractMediator {protected AbstractColleague A; protected AbstractColleague B; public AbstractMediator (AbstractColleague a, AbstractColleague B) {A = a; B = B ;} public abstract void AaffectB (); public abstract void BaffectA ();} class Mediator extends AbstractMediator {public Mediator (AbstractColleague a, AbstractColleague B) {super (a, B );} // process the effect of A on B public void AaffectB () {int number =. getNumber (); B. setNumber (number * 100);} // process the impact of B on A public void BaffectA () {int number = B. getNumber ();. setNumber (number/100) ;}} public class Client {public static void main (String [] args) {AbstractColleague collA = new ColleagueA (); AbstractColleague collB = new ColleagueB (); abstractMediator am = new Mediator (collA, collB); System. out. println ("=========== influence B by setting A ==========="); collA. setNumber (1000, am); System. out. println ("the number value of collA is:" + collA. getNumber (); System. out. println ("the number value of collB is 10 times of A:" + collB. getNumber (); System. out. println ("=========== influence A by setting B ==========="); collB. setNumber (1000, am); System. out. println ("the number value of collB is:" + collB. getNumber (); System. out. println ("the number value of collA is 0.1 times of B:" + collA. getNumber ());}}

Although the Code is long, it is easy to understand. In fact, it is to re-encapsulate the code that originally processes the object relationship into an intermediary class to process the relationship between objects through this intermediary class.

Advantages of intermediary Mode

1. Using the intermediary mode appropriately can avoid excessive coupling between the colleagues' classes so that they can be used relatively independently.
2. The intermediary mode can be used to convert one-to-many associations between objects into one-to-one associations, making the relationships between objects easy to understand and maintain.
3. The intermediary mode can be used to abstract the behavior and collaboration of objects, so as to flexibly process the interaction between objects.

Applicable scenarios

In object-oriented programming, a class is bound to be dependent on other classes, and completely independent classes are meaningless. It is also quite common that a class depends on multiple classes at the same time. In this case, one-to-many dependencies are rational, the proper use of the intermediary mode can clear the original messy object relationship, but abuse may result in reverse effects. Generally, the intermediary mode is considered only when the relationship between colleague classes is in a mesh structure. The mesh structure can be changed to a star structure, so that the relationship between colleagues and classes becomes clearer.

Intermediary mode is a common mode and a mode that is easy to abuse. In most cases, the relationships between colleague classes are not complex to messy mesh structures. Therefore, in most cases, the inter-object dependency can be encapsulated inside the colleague classes, there is no need to introduce the intermediary mode. Misuse of the intermediary model only makes things more complicated.

The above is all the content of this article. I hope it will be helpful for your learning and support for helping customers.