23 design modes 20: Java intermediary model
Definition: Encapsulate a series of object interactions with a mediator object. The mediator makes each object interact without display, thereby loosening the coupling and independently changing the interaction between them.
Type: Behavioral Pattern
Class diagram:
The structure of the intermediary model
The intermediary mode is also called the mediator mode. From the class diagram, it is divided into 3 parts:
Abstract mediator: define the interface between colleague class objects and mediator objects, and is used for communication between each colleague class. Generally, it includes one or several abstract event methods and is implemented by subclasses.
Intermediary implementation class: inherited from abstract mediators and implements event methods defined in abstract mediators. Receive messages from one colleague class and then influence other simultaneous classes through the message.
Colleague class: If an object affects other objects and is also affected by other objects, then these two objects are called colleague classes. In the class diagram, there is only one colleague class, which is actually an omission of reality. In practical applications, the colleague class is generally composed of multiple, and they influence and depend on each other. The more colleagues there are, the more complicated the relationships. Moreover, the colleague class can also be represented as a set of implementations inheriting the same abstract class. In the intermediary model, the message must be transmitted through intermediaries between colleagues.
Why use the intermediary model
Generally speaking, the relationship between colleague classes is relatively complex. When multiple colleague classes are correlated, their relationship will appear as a complex mesh structure. This is an over-coupled architecture, that is, it is not conducive to class reuse and is not stable. For example, in the figure below, there are six colleague-like objects. If object 1 changes, 4 objects will be affected. If object 2 changes, then 5 objects will be affected. In other words, the design of direct correlation between colleagues is not good.
If the intermediary model is introduced, the relationship between colleague classes will become a star structure. From the figure, we can see that the changes in any class will only affect the class itself and the intermediary, which will reduce the coupling of the system. A good design will definitely not encapsulate all object-relationship processing logic in this class, but will use a special class to manage 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, and we must ensure that the numbers in class B are always 100 times the numbers in class A. That is to say, when modifying the number of class A, multiplying the number by 100 and assigning it to class B, and when modifying class B, divide the number by 100 and assign it to class A. Class A and B affect each other, so they are called colleagues. The code is as follows:
abstract class AbstractColleague { protected int number; public int getNumber() { return number; } public void setNumber(int number){ this.number = number; } //Abstract method, modify the associated object at the same time when modifying numbers public abstract void setNumber(int number, AbstractColleague coll); } class ColleagueA extends AbstractColleague{ 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("====================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================== System.out.println("collB's number value: "+collB.getNumber()); System.out.println("collA's number value: "+collA.getNumber()); } } In the above code, class A and B are related through direct association. If we want to use the intermediary model, class A and B cannot be directly related. They must use an intermediary to achieve the purpose of association.
abstract class AbstractColleague { protected int number; public int getNumber() { return number; } public void setNumber(int number){ this.number = number; } //Note that the parameters here are no longer colleagues, but an intermediary public abstract void setNumber(int number, AbstractMediator am); } class ColleagueA extends AbstractColleague{ public void setNumber(int number, AbstractMediator am) { this.number = number; am.AaffectB(); } } class ColleagueB extends AbstractColleague{ @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); } //handle the impact of A on B public void AaffectB() { int number = A.getNumber(); B.setNumber(number*100); } //handle the impact of B on A public void BaffectA() { int number = B.getNumber(); A.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("======================== Effect by setting A======================================================================================================================================================================================================================================================================================================================================================================================== System.out.println("collA's number value is: "+collA.getNumber()); System.out.println("collB's number value is 10 times A: "+collB.getNumber()); System.out.println("==================== A by setting B===================================================================================================================================================================================================================================================================================================================================================================== System.out.println("collB's number value is: "+collB.getNumber()); System.out.println("collA's number value is 0.1 times B: "+collA.getNumber()); } }Although the code is relatively long, it is still relatively easy to understand. In fact, it is to repackage the code that originally handles object relationships into a mediation class, and handle the relationship between objects through this mediation class.
Advantages of the intermediary model
1. Appropriate use of the intermediary model can avoid excessive coupling between colleague classes, so that each colleague class can be used relatively independently.
2. Using the mediator pattern can transform one-to-many relationships between objects into one-to-one relationships, making the relationships between objects easy to understand and maintain.
3. Using the intermediary model can abstract the behavior and collaboration of objects, and can handle interactions between objects more flexibly.
Applicable scenarios
In object-oriented programming, a class will inevitably depend 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 such a situation exists, it means that the one-to-many dependency has its rationality. Appropriate use of the mediator pattern can make the originally messy object relationship clear, but if it is abused, it may bring negative effects. Generally speaking, the mediator model is considered only for the relationship between coworker classes where there is a mesh structure. The mesh structure can be transformed into a star structure to make the relationship between colleagues clearer.
The intermediary model is a relatively common model and a relatively easy-to-be abused model. In most cases, the relationship between colleague classes will not be complicated to a chaotic mesh structure. Therefore, in most cases, it is OK to encapsulate the dependencies between objects within the colleague class, and there is no need to introduce the intermediary model. Abuse of the intermediary model will only make things more complicated.
The above is all the content of this article. I hope it will be helpful to everyone's learning and I hope everyone will support Wulin.com more.