17370845950

Go中中介者模式不用class和继承，因Go无类与继承机制；应以结构体承载协调逻辑，用函数字段或方法注入行为，同事仅弱引用中介者，避免循环依赖与过度耦合。

中介者模式在 Go 里为什么不用 class 和继承

Go 没有类、没有继承、也没有 abstract 关键字，所以传统 UML 里的 Mediator 抽象类和 Colleague 基类无法直接翻译。强行用接口模拟抽象类，反而会让协作逻辑散落在各处，失去中介者“集中协调”的本意。

更自然的做法是：用一个结构体承载协调逻辑，用函数字段或方法接收具体行为，同事对象只保留对中介者的弱引用（如 *Mediator 或函数类型）。

• 同事不持有其他同事的引用，只认得中介者
• 中介者持有所有需要协调的组件（可以是 struct 字段、map、或切片）
• 避免循环导入：把中介者定义放在独立包，或与核心业务逻辑同层

如何定义可复用的 Mediator 结构体

中介者不是模板，而是针对具体协作场景定制的协调器。比如聊天室、订单状态同步、UI 组件联动——每种场景下，“谁通知谁”“什么条件下转发”都不同。

典型结构包含三部分：被协调对象的注册容器、事件分发逻辑、以及可注入的响应函数。

type ChatRoom struct {
	users map[string]func(string) // 用户名 → 接收消息的回调
}

func (c *ChatRoom) Register(name string, handler func(string)) {
	c.users[name] = handler
}

func (c *ChatRoom) Broadcast(sender, msg s
tring) {
	for name, h := range c.users {
		if name != sender {
			h("[" + sender + "] " + msg)
		}
	}
}

• users 是 map 而非 slice：便于按用户名快速查找/移除
• handler 类型为 func(string)：解耦具体用户实现，调用方自己决定怎么处理消息
• 不暴露 users 字段：防止外部绕过 Broadcast 直接调用

同事对象如何安全持有中介者引用

同事对象（比如 User）不能直接依赖具体中介者类型，否则会提高耦合度。推荐两种轻量方式：

• 用函数字段替代结构体字段：onMessage func(string)，由中介者在注册时注入
• 若需双向通信（如用户主动发言），则持有一个指向中介者的指针：mediator *ChatRoom，但仅调用其公开方法

错误写法示例：mediator MediatorInterface —— Go 中接口应由调用方定义，而非中介者强推。

type User struct {
	name       string
	onMessage  func(string) // 收到消息时执行
	mediator   *ChatRoom    // 需要发言时用
}

func (u *User) Send(msg string) {
	if u.mediator != nil {
		u.mediator.Broadcast(u.name, msg)
	}
}

func (u *User) Receive(msg string) {
	if u.onMessage != nil {
		u.onMessage(msg)
	}
}

注意：onMessage 和 mediator 不同时必需；根据协作方向选择其一即可。

什么时候不该用中介者模式

中介者容易变成“上帝对象”，尤其当所有状态变更都塞进一个结构体里时。以下情况建议跳过中介者：

• 只有两个对象交互，且逻辑简单 → 直接互相调用更清晰
• 协作规则随业务频繁变化 → 把逻辑写死在 Mediator 里会导致频繁修改，不如用事件总线（如 github.com/ThreeDotsLabs/watermill）
• 需要跨进程/跨服务协调 → 单机内存结构无法满足，应交由消息队列或状态机服务

真正值得上中介者的，是那些「对象数量中等（3–8 个）、交互关系密集、且生命周期基本一致」的模块，比如表单校验组件组、游戏内 NPC 行为调度器。