中介者模式通过引入中介者对象解耦多个同事对象间的复杂交互，将网状通信转为星型结构。在Golang中，利用接口和组合可实现该模式，典型应用如聊天室示例：User结构体通过ChatRoom中介者发送消息，避免直接依赖；扩展的事件驱动中介者支持多种事件类型，适用于微服务解耦。关键在于保持中介者职责单一，防止过度设计，结合接口与context提升可测试性与健壮性，适用于GUI、游戏、IoT等高频交互场景。
中介者模式用于解耦多个对象之间的复杂交互，将原本分散在多个对象中的通信逻辑集中到一个中介者对象中统一处理。在 Golang 中，虽然没有类和继承的语法支持，但通过接口和组合可以优雅地实现这一行为型设计模式，尤其适合用于状态管理、组件通信或模块解耦等场景。
理解中介者模式的核心结构
中介者模式包含两个关键角色：中介者（Mediator）和同事对象（Colleague）。同事对象不再直接通信，而是通过中介者进行消息传递。这样可以避免对象之间形成网状依赖，转为星型结构，提升可维护性。
在 Golang 中，通常定义一个 Mediator 接口，以及多个 Colleague 结构体，它们持有对中介者的引用。当某个同事对象状态变化时，它通知中介者，由中介者决定如何协调其他对象。
核心要点：- 定义 Mediator 接口，声明协调方法
- 同事对象不直接引用彼此，只依赖中介者
- 中介者知道所有同事对象，并可在内部调度其行为
用接口与结构体实现松耦合通信
下面是一个实际例子：模拟聊天室中的用户通信。每个用户（User）发送消息时不直接发给其他人，而是通过聊天室（ChatRoom）这个中介者进行广播。
立即学习“go语言免费学习笔记（深入）”；
先定义中介者接口和用户结构：
type Mediator interface {
Send(message string, sender User)
}
type User struct {
Name string
ChatRoom Mediator
}
func (u *User) Send(message string) {
u.ChatRoom.Send(message, *u)
}
func (u *User) Receive(message string) {
println(u.Name + " received: " + message)
}
然后实现具体的中介者 ChatRoom：
type ChatRoom struct {
Users []*User
}
func (c *ChatRoom) AddUser(user *User) {
user.ChatRoom = c
c.Users = append(c.Users, user)
}
func (c *ChatRoom) Send(message string, sender User) {
for _, user := range c.Users {
if user.Name != sender.Name {
user.Receive(message)
}
}
}
使用方式如下：
room := &ChatRoom{}
alice := &User{Name: "Alice"}
bob := &User{Name: "Bob"}
room.AddUser(alice)
room.AddUser(bob)
alice.Send("Hi Bob!") // Bob 收到消息
可以看到，User 之间没有直接依赖，新增用户也不会影响现有逻辑。
高级实践：事件驱动的中介者
在更复杂的系统中，可以扩展中介者为事件总线，支持多种消息类型和订阅机制。例如，使用 channel 实现异步通信，或通过注册回调函数响应特定事件。
示例：支持事件类型的中介者
type EventType string
const (
EventLogin EventType = "login"
EventLogout EventType = "logout"
EventChat EventType = "chat"
)
type EventMediator interface {
Notify(event EventType, data map[string]any)
}
type SystemMediator struct {
services []Service
}
func (m *SystemMediator) Notify(event EventType, data map[string]any) {
for _, svc := range m.services {
svc.HandleEvent(event, data)
}
}
type Service interface {
HandleEvent(event EventType, data map[string]any)
}
这种模式适用于微服务模块间解耦，比如用户登录后触发日志记录、通知推送等操作，均由中介者统一调度。
避免过度设计与循环依赖
中介者模式虽好，但需注意不要滥用。如果对象间交互简单，引入中介者反而增加复杂度。同时要防止中介者变得过于庞大，变成“上帝对象”。
建议做法：
- 保持中介者职责单一，必要时拆分多个中介者
- 使用接口而非具体类型，便于测试和替换
- 结合 context 控制超时和取消，提升健壮性
- 在 GUI 系统、游戏对象管理、IoT 设备控制等高频交互场景中优先考虑使用
基本上就这些。Golang 的简洁性和接口设计让中介者模式实现起来既清晰又灵活，关键是把握好解耦的粒度。
