中介者模式通过引入中间人协调对象间通信，降低耦合度，适用于多个对象存在复杂且易变交互的场景，如聊天室、ui控件协同、工作流引擎等；其优点包括解耦同事对象、集中控制交互逻辑、简化对象职责，缺点是中介者可能变得复杂庞大，增加系统抽象层级并带来性能开销；为避免中介者过度复杂，应进行职责分离、使用组合、结合观察者模式或选用其他设计模式，实际应用中需权衡利弊，避免过度设计。
中介者模式，简单来说，就是让一堆对象不用直接互相说话，而是找个“中间人”来传话。用 Golang 实现，能有效降低对象间的耦合度，让系统更灵活。
解决方案
实现中介者模式，核心在于定义一个中介者接口，以及让各个“同事”对象持有该中介者的引用。同事对象间的通信，都通过中介者进行。
立即学习“go语言免费学习笔记（深入）”；
- 定义中介者接口：
type Mediator interface {
Register(name string, colleague Colleague)
Send(from string, to string, message string)
}- 定义同事接口：
type Colleague interface {
Receive(from string, message string)
Send(to string, message string)
SetName(name string)
}- 实现具体的中介者：
type ConcreteMediator struct {
colleagues map[string]Colleague
}
func NewConcreteMediator() *ConcreteMediator {
return &ConcreteMediator{
colleagues: make(map[string]Colleague),
}
}
func (m *ConcreteMediator) Register(name string, colleague Colleague) {
m.colleagues[name] = colleague
colleague.SetName(name)
}
func (m *ConcreteMediator) Send(from string, to string, message string) {
colleague, ok := m.colleagues[to]
if !ok {
fmt.Println("找不到接收者:", to)
return
}
colleague.Receive(from, message)
}- 实现具体的同事类：
type ConcreteColleague struct {
mediator Mediator
name string
}
func NewConcreteColleague(mediator Mediator) *ConcreteColleague {
return &ConcreteColleague{
mediator: mediator,
}
}
func (c *ConcreteColleague) Receive(from string, message string) {
fmt.Printf("%s 收到来自 %s 的消息: %s\n", c.name, from, message)
}
func (c *ConcreteColleague) Send(to string, message string) {
fmt.Printf("%s 发送消息给 %s: %s\n", c.name, to, message)
c.mediator.Send(c.name, to, message)
}
func (c *ConcreteColleague) SetName(name string) {
c.name = name
}- 使用示例：
func main() {
mediator := NewConcreteMediator()
colleague1 := NewConcreteColleague(mediator)
colleague2 := NewConcreteColleague(mediator)
mediator.Register("Alice", colleague1)
mediator.Register("Bob", colleague2)
colleague1.Send("Bob", "你好，Bob!")
colleague2.Send("Alice", "Alice你好，我是Bob!")
}Golang 中介者模式在实际项目中的应用场景有哪些？
中介者模式并非银弹，滥用反而会增加系统的复杂性。比较适合的场景是：
- 多个对象之间存在复杂的交互关系，且这些关系容易变化。 例如，一个在线聊天室，用户之间可以互相发送消息，管理员可以禁言用户等。
- 需要避免对象之间的直接依赖，降低耦合度。 例如，一个 UI 系统，多个控件之间需要协同工作，但又不希望它们直接互相调用。
- 需要集中控制对象之间的交互行为。 例如，一个工作流引擎，需要根据不同的条件触发不同的任务。
在这些场景下，使用中介者模式可以使系统结构更清晰、更易于维护。当然，如果对象之间的交互关系非常简单，或者变化的可能性很小，那么直接让对象互相调用可能更简单直接。
如何避免中介者模式中中介者对象过于复杂？
中介者对象承担了协调各个同事对象的职责，很容易变得过于庞大和复杂，成为一个“上帝对象”。避免这种情况，可以考虑以下几点：
- 职责分离： 将中介者对象的职责进行分解，例如，可以将消息路由、权限控制、状态管理等职责分别交给不同的组件来处理。
- 使用组合： 将多个简单的中介者对象组合成一个更复杂的中介者对象。
- 引入观察者模式： 让同事对象订阅中介者对象的状态变化，从而减少中介者对象需要直接控制的同事对象的数量。
- 考虑使用其他设计模式： 有时候，中介者模式并不是解决问题的最佳方案，可以考虑使用其他的模式，例如命令模式、责任链模式等。
总而言之，要根据实际情况，灵活运用设计模式，避免过度设计。
除了集中管理对象间的交互，中介者模式还有哪些优点和缺点？
优点：
- 降低耦合度： 这是中介者模式最核心的优点。同事对象之间不再直接依赖，而是通过中介者进行通信，从而降低了耦合度，提高了系统的灵活性和可维护性。
- 集中控制： 中介者对象可以集中控制对象之间的交互行为，方便进行统一的管理和控制。例如，可以添加权限控制、日志记录等功能。
- 简化对象： 同事对象只需要关注自身的职责，不需要关心与其他对象的交互细节，从而简化了对象的设计。
缺点：
- 中介者对象可能变得过于复杂： 如果同事对象之间的交互关系非常复杂，那么中介者对象可能会变得非常庞大和复杂，难以维护。
- 增加了系统的复杂性： 引入中介者模式会增加系统的复杂性，需要仔细权衡是否值得。
- 性能问题： 所有对象之间的通信都需要通过中介者进行转发，可能会带来一定的性能损失。
在决定是否使用中介者模式时，需要综合考虑其优缺点，并根据实际情况进行选择。
