Mediator pattern in Go design pattern

Yuxian: CSDN content partner, CSDN new star mentor, full-stack creative star creator, 51CTO (Top celebrity + expert blogger), github open source enthusiast (go-zero source code secondary development, game back-end architecture https: https://github.com/Peakchen)

 

The principle of the mediator pattern is explained in detail:
the mediator pattern (Mediator Pattern) is a behavioral design pattern, which is used to reduce the direct communication between multiple objects and make them interact through a mediator object.

The core idea of ​​the intermediary pattern is to concentrate the complex interaction logic between multiple objects in one intermediary object, thereby reducing the coupling between various objects. The mediator object acts as a scheduler and coordinator between objects, responsible for handling communication and interaction between objects.

The mediator pattern usually includes the following roles:

• Mediator: Defines the communication interface between objects and is responsible for coordinating the interaction between objects.
• Concrete Mediator: implement the mediator interface, and specifically handle the communication and interaction logic between objects.
• Colleague: Defines the interface for communication between objects and maintains a reference to the intermediary object.
• Specific colleague class (Concrete Colleague): implement the colleague class interface, and communicate with other colleague classes through the intermediary object.

Underlying structure diagram:
The following is a classic structure diagram of the intermediary model:

+-----------------+        +-----------------+
|    Mediator        |        |    Colleague       |
+-----------------+        +-----------------+
| +SendMessage() |<>------| +ReceiveMessage() |
+-----------------+        +-----------------+
        ▲
        |
        |
+-----------------+
| ConcreteMediator |
+-----------------+
| +colleague1         |
| +colleague2         |
| +colleague3         |
| +...                     |
+-----------------+

In the above structure diagram, Mediator it is the role of the intermediary, which defines the communication interface between objects. It usually contains one or more methods, eg  SendMessage(), for sending messages to other fellow classes.

Colleague It is the role of the colleague class, which defines the interface for communication between objects. It maintains a reference to the Mediator object and communicates by calling methods on the Mediator.

ConcreteMediator It is the role of a specific intermediary, which implements the intermediary interface and specifically handles the communication and interaction logic between objects. It contains references to each colleague class and calls methods of each colleague class as needed.

Scenario Explanation:
The Intermediary Mode applies to the following scenarios:

1. When there is complex interaction logic between multiple objects, resulting in a high degree of coupling between objects, you can consider using the intermediary pattern. The intermediary mode can concentrate the complex interaction logic in the intermediary object, which makes the communication between various objects simple and reduces the direct dependencies between objects.

2. The Mediator pattern can be used when a Mediator object is required to coordinate and schedule interactions between multiple objects. The intermediary mode can centrally manage the communication between objects and provide better maintainability and scalability.

3. When you want to change the interaction between objects by adding or modifying mediator objects, you can consider using the Mediator pattern. The mediator pattern encapsulates the interaction logic between objects in the mediator object, so the interaction mode between objects can be changed by modifying the mediator object without modifying each colleague class.

Code example implementation:
The following is an example of using the Go language to implement the Mediator pattern:

package main

import "fmt"

// Mediator 中介者
type Mediator interface {
	SendMessage(colleague Colleague, message string)
}

// Colleague 同事类
type Colleague interface {
	ReceiveMessage(message string)
}

// ConcreteMediator 具体中介者
type ConcreteMediator struct {
	colleague1 Colleague
	colleague2 Colleague
}

func (m *ConcreteMediator) SendMessage(colleague Colleague, message string) {
	if colleague == m.colleague1 {
		m.colleague2.ReceiveMessage(message)
	} else if colleague == m.colleague2 {
		m.colleague1.ReceiveMessage(message)
	}
}

// ConcreteColleague1 具体同事类1
type ConcreteColleague1 struct {
	mediator Mediator
}

func (c *ConcreteColleague1) ReceiveMessage(message string) {
	fmt.Println("ConcreteColleague1 received:", message)
}

func (c *ConcreteColleague1) SendMessage(message string) {
	c.mediator.SendMessage(c, message)
}

// ConcreteColleague2 具体同事类2
type ConcreteColleague2 struct {
	mediator Mediator
}

func (c *ConcreteColleague2) ReceiveMessage(message string) {
	fmt.Println("ConcreteColleague2 received:", message)
}

func (c *ConcreteColleague2) SendMessage(message string) {
	c.mediator.SendMessage(c, message)
}

func main() {
	mediator := &ConcreteMediator{}

	colleague1 := &ConcreteColleague1{
		mediator: mediator,
	}

	colleague2 := &ConcreteColleague2{
		mediator: mediator,
	}

	mediator.colleague1 = colleague1
	mediator.colleague2 = colleague2

	colleague1.SendMessage("Hello from ConcreteColleague1")
	colleague2.SendMessage("Hello from ConcreteColleague2")
}

In the above example, we defined  Mediator interface and  Colleague interface, representing the role of mediator and colleague class respectively. Then, we implemented the concrete mediator  ConcreteMediator and two concrete colleague classes  ConcreteColleague1 and  ConcreteColleague2.

In  ConcreteMediator , we use  SendMessage methods to achieve communication between colleagues. In  ConcreteColleague1 and  ConcreteColleague2 , we implement  ReceiveMessage the and  SendMessage methods to receive and send messages respectively.

Finally, in  main the function, we create the mediator object and two colleagues class objects and associate them with each other. Then,  SendMessage send the message by calling a method of the colleague class.

Links to Literature:
Here are some links to literature and references about the Mediator pattern:

1. Design Patterns: Elements of Reusable Object-Oriented Software (GoF Book) - Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides ("Design Patterns: Elements of Reusable Object-Oriented
   Software" - Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides)

2. Mediator Pattern - SourceMaking
   (Intermediary mode - SourceMaking)
   Mediator Design Pattern

3. Mediator Design Pattern in Go - Tutorialspoint
   (Mediator Design Pattern in Go - Tutorialspoint)
   Design Patterns - Mediator Pattern | Tutorialspoint

Which products are currently in use:
The Mediator pattern is a common design pattern that is widely used in software development. Many products and frameworks use the Mediator pattern in their internal or public APIs to handle communication and interaction between objects.

Here are some common products and frameworks that might use the Mediator pattern or similar design patterns:

1. GUI frameworks (such as Java Swing, JavaFX, Qt, etc.): These frameworks usually use the mediator pattern to coordinate the interaction between interface components, such as button clicks, menu selections, etc.

2. Messaging middleware (such as Apache Kafka, RabbitMQ, etc.): These messaging middleware use the mediator pattern to handle messaging and interaction in a publish-subscribe model.

3. Chat apps (such as WeChat, Slack, etc.): These apps use a mediator pattern to handle chat messaging and interactions between users.

4. Game engine (such as Unity, Unreal Engine, etc.