Design Pattern: Mediator Pattern

Although dividing a system into many objects generally increases its reusability, the proliferation of interconnections between objects reduces its reusability.

A large number of connections make it impossible for one object to work without the support of other objects, and the system behaves as an indivisible whole. Therefore, it becomes very difficult to make large changes to the behavior of the system.

The next step is to use the mediator pattern.

Mediator pattern (Mediator): Use a mediator object to encapsulate a series of object interactions. The mediator makes the objects do not need to explicitly refer to each other, so that it is loosely coupled, and can independently change the interaction between them.

Mediator class, abstract mediator class

abstract class Colleague{
    //Define an abstract method of sending information, get the colleague object and send the information
    public abstract void Send(String message, Colleague colleague);
}

Colleague class abstract colleague class

abstract class Colleague{
    protected Mediator mediator;
    //Constructor method to get the mediator object
    public Colleague(Mediator mediator){
        this.mediator = mediator;
    }
}

ConcreteMediator class Concrete mediator class

classs ConcreteMediator implements Mediator{
    private ConcreteColleague1 colleague1;
    private ConcreteColleague2 colleague2;
    //Need to know all the specific colleague objects
    public ConcreteColleague1 setColleague1(ConcreteColleague1 value){
        colleague1 = value;
    }

    public ConcreteColleague2 setColleague(ConcreteColleague2 value){
        colleague1 = value;
    }

    //Rewrite the method of sending information, make a selection judgment according to the object, and notify the object
    public void Send(String message , Colleague colleague){
        if (colleague == colleague1) {
            colleague2.Notify(message);
        }else{
            colleague1.Notify(message);
        }
    }
}

Various colleague objects like ConcreteColleague1 and ConcreteColleague2

class ConcreteColleague1 implements Colleague{
    public Mediator mediator;

    public void Send(String message){
        //When sending information, it is usually sent by an intermediary
        mediator.Send(message,this);
    }

    public void Notify(String message){
        System.out.println("Colleague 1 got message: " +message);
    }
}

class ConcreteColleague2 implements Colleague{
    public Mediator mediator;

    public void Send(String message){
        //When sending information, it is usually sent by an intermediary
        mediator.Send(message,this);
    }

    public void Notify(String message){
        System.out.println("Colleague 2 got message: " +message);
    }
}

Client call

ConcreteMediator m = new ConcreteMediator();
//Let two specific colleague classes know the mediator object
ConcreteColleague1 c1 = new ConcreteColleague1(m);
ConcreteColleague2 c2 = new ConcreteColleague2(m);
//Let the intermediary know each specific colleague class object
m.Colleague1 = c1;
m.Colleague2 = c2;
//The information sent by the specific colleague class object is forwarded through the intermediary
c1.Send("Have you eaten?");
c2.Send("No, have you eaten?");

Advantages and disadvantages of the mediator model

      The mediator mode is easy to apply in the system, and it is easy to be misused in the system. When there is a complex object group with 'many-to-many' interaction in the system, don't rush to use the mediator mode, but first reflect on how your system works. Is the design reasonable?

     The advantage of the mediator mode is the emergence of Mediator, which reduces the coupling of each Colleague, so that each Colleague class and Mediator can be changed and reused independently. Because the object such as song collaboration is abstracted, the mediation is regarded as an independent concept and is integrated. Encapsulate it in an object, so that the object of interest is transferred from the behavior of the object's respective objects to the interaction between them, that is, to look at the system from a macro perspective.

     Since the ConcreteMediator controls the centralization, it turns the interaction complexity into the reusability of the mediator, which makes the mediator more complex than any ConcreteColleague.

      The Mediator pattern is generally used when a set of objects communicate in a well-defined but complex way, and when you want to customize the behavior of a class that is distributed across multiple classes, without creating too many subclasses.