This is the 26th day of my participation in the August Text Challenge.More challenges in August

The mediator pattern

Define a mediation object that encapsulates the interactions between a set of objects, loosens the coupling between the original objects, and can change their interactions independently. A typical application of Demeter's ruleCopy the code

structure

1. Mediator role: It is the Mediator’s interface and provides an abstract method for colleague objects to register and forward their information.
2. Concrete Mediator role: Implements the Mediator interface, defines a List to manage colleague objects, and coordinates the interactions between various colleague roles, so it relies on the colleague role.
3. Colleague roles: Define interfaces to Colleague classes, hold mediator objects, provide abstract methods for Colleague object interaction, and implement common functions of all interacting Colleague classes.
4. A Concrete Colleague role: is an implementer of an abstract Colleague class. When it is necessary to interact with other Colleague objects, the intermediary objects are responsible for subsequent interactions.

demo

Simulate a chat group that is responsible for adding users and forwarding messages submitted by usersCopy the code

1. Abstract intermediaries

public abstract class Mediator {
    List<Colleague> list = new ArrayList<>();
    public void add(Colleague colleague) {
        if (list.contains(colleague)) {
            System.out.println("Current user already exists!");
        } else {
            colleague.setMedium(this); list.add(colleague); }}public abstract void forward(Colleague colleague, String message);
}
Copy the code

2. Specific intermediaries

public class ChatGroup extends Mediator {
    @Override
    public void forward(Colleague colleague, String message) {
        for (Colleague item : list) {
            if(! item.equals(colleague)) { System.out.println(item.getClass().getSimpleName() +"Receive" + colleague.getClass().getSimpleName() + "Message sent:"+ message); }}}}Copy the code

3. Abstract colleague classes

public abstract class Colleague {
    protected Mediator mediator;
    public void setMedium(Mediator mediator) {
        this.mediator = mediator;
    }
    public abstract void send(String message);
}
Copy the code

4. Specific colleagues

public class UserOne extends Colleague{
    @Override
    public void send(String message) {
        System.out.println(this.getClass().getSimpleName() + "Send a message:" + message);
        this.mediator.forward(this, message); }}public class UserTwo extends Colleague {
    @Override
    public void send(String message) {
        System.out.println(this.getClass().getSimpleName() + "Send a message:" + message);
        this.mediator.forward(this, message); }}Copy the code

5. Client

public class Client {
    public static void main(String[] args) {
        Mediator group = new ChatGroup();
        Colleague user1 = new UserOne();
        Colleague user2 = new UserTwo();
        group.add(user1);
        group.add(user2);
        user1.send("hello");
        // UserOne sends a message: hello
        // UserTwo receives a message from UserOne: hello}}Copy the code

conclusion

advantages

1. Only pay attention to their own responsibilities between various types, such as the code above, the user is only responsible for sending messages, in line with Demeter’s law.

2, reduce the coupling between objects, make objects easy to reuse independently

3. Change the many-to-many relationship of objects into one-to-one relationship, improve the flexibility of the system, and facilitate maintenance and expansion

disadvantages

1. The intermediary is responsible for interacting with each object. The more colleague classes there are, the more bloated and complex the intermediary will become