Detailed explanation of Java design patterns about the mediator pattern (picture)

This article mainly introduces the relevant information of the intermediary pattern of the design pattern in detail, which has certain reference value. Interested friends can refer to it

Definition:Use a mediator object to encapsulate a series of object interactions. The mediator allows each object to interact without explicit interaction, thus loosening the coupling and allowing the interaction between them to be changed independently.

Type: Behavioral class pattern

Class diagram:

Mediator pattern The structure of

The mediator pattern is also called the mediator pattern. From the class diagram, it is divided into 3 parts:

Abstract Mediator: Definition The interface from the good colleague class object to the mediator object is used for communication between various colleague classes. Generally includes one or several abstract event methods, and are implemented by subclasses.

Mediator implementation class: Inherited from abstract mediator, implements event methods defined in abstract mediator. Receives messages from a peer class and then affects other concurrent 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, colleague classes are generally composed of multiple ones, and they interact and depend on each other. The more types of colleagues there are, the more complex the relationship becomes. Moreover, the colleague class can also be represented as a group of implementations that inherit the same abstract class. In the mediator pattern, messages must be passed between coworker classes through a mediator.

Why use the intermediary pattern

Generally speaking, the relationship between colleague classes is relatively complex, and multiple colleague classes are related to each other. Sometimes, the relationship between them will appear as a complex network structure. This is an over-coupled architecture that is not conducive to class reuse and is unstable. For example, in the figure below, there are six co-worker class 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 co-worker classes is not good.

If the mediator pattern is introduced, the relationship between colleague classes will become a star structure. As can be seen from the figure, any Class changes will only affect the class itself and the mediator, thus reducing the coupling of the system. A good design will not encapsulate all object relationship processing logic in this class, but use a special class to manage behaviors that do not belong to you.

We use an example to illustrate what a colleague class is: there are two classes A and B, each has a number in the class, and the number in class B must be guaranteed It is always 100 times the number in class A. That is, when modifying a number in class A, multiply the number by 100 and assign it to class B, and when modifying class B, divide the number by 100 and assign it to class A. Class A and class B interact with each other and are called co-classes. The code is as follows:

abstract class AbstractColleague { 
  protected int number; 
 
  public int getNumber() { 
    return number; 
  } 
 
  public void setNumber(int number){ 
    this.number = number; 
  } 
  //抽象方法，修改数字时同时修改关联对象 
  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("==========设置A影响B=========="); 
    collA.setNumber(1288, collB); 
    System.out.println("collA的number值："+collA.getNumber()); 
    System.out.println("collB的number值："+collB.getNumber()); 
 
    System.out.println("==========设置B影响A=========="); 
    collB.setNumber(87635, collA); 
    System.out.println("collB的number值："+collB.getNumber()); 
    System.out.println("collA的number值："+collA.getNumber()); 
  } 
}

In the above code, class A and class B are related through direct association. If we want to use the intermediary mode, class A and class B They cannot be directly related, and they must go through 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; 
  } 
  //注意这里的参数不再是同事类，而是一个中介者 
  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); 
  } 
 
  //处理A对B的影响 
  public void AaffectB() { 
    int number = A.getNumber(); 。
    B.setNumber(number*100); 
  } 
 
  //处理B对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("==========通过设置A影响B=========="); 
    collA.setNumber(1000, am); 
    System.out.println("collA的number值为："+collA.getNumber()); 
    System.out.println("collB的number值为A的10倍："+collB.getNumber()); 
 
    System.out.println("==========通过设置B影响A=========="); 
    collB.setNumber(1000, am); 
    System.out.println("collB的number值为："+collB.getNumber()); 
    System.out.println("collA的number值为B的0.1倍："+collA.getNumber()); 
     
  } 
}

Although the code is relatively long, it is still relatively easy to understand. In fact, it is to re-encapsulate the original code that handles object relationships into an intermediary class. Through this Intermediary classes handle relationships between objects.

Advantages of the mediator pattern

 Proper use of the mediator pattern can avoid excessive coupling between colleague classes, making each colleague class can be used relatively independently.
Using the mediator pattern can transform the one-to-many association between objects into a one-to-one association, making the relationship between objects easy to understand and maintain.
Using the mediator pattern can abstract the behavior and collaboration of objects, and can handle the interaction between objects more flexibly.

Applicable scene

In object-oriented programming, a class will inevitably have dependencies on other classes, and completely independent classes are meaningless. It is also quite common for a class to depend on multiple classes at the same time. Since such a situation exists, it means that the one-to-many dependency relationship has its rationality. Appropriate use of the mediator pattern can make the originally messy object relationship clear, but if Abuse may have the opposite effect. Generally speaking, the mediator pattern will be considered only for relationships with a network structure between co-worker classes. You can change the network structure into a star structure to make the relationship between classes clearer.

The intermediary model is a commonly used model, and it is also a model that is easily abused. For most cases, the relationship between colleague classes will not be as complicated as a chaotic network structure. Therefore, in most cases, it is enough to encapsulate the dependencies between objects inside the colleague classes. There is no need to introduce intermediaries. or mode. Abusing the intermediary model will only make things more complicated.

The above is the detailed content of Detailed explanation of Java design patterns about the mediator pattern (picture). For more information, please follow other related articles on the PHP Chinese website!