Go 中不应使用 Mediator 接口，因其导致类型丢失、字符串事件难维护；应改用函数字段或 channel 实现类型安全、内聚且易测试的协作机制。
Go 语言没有类继承和接口实现的强制约束，也不鼓励用“模式”套代码，所以直接照搬 Java 风格的中介者模式（Mediator Pattern）往往会导致过度设计、接口膨胀、运行时反射滥用——这在 Go 里既不必要，也难维护。
为什么 Mediator 接口在 Go 里通常是个坏主意
很多教程一上来就定义 type Mediator interface { Notify(sender interface{}, event string) }，看似抽象，实则埋坑：
-
sender interface{}让类型信息丢失，编译期无法检查谁该发什么事件 - 事件名用
string，拼错无提示，重构困难，IDE 不支持跳转 - 所有组件都得持有
Mediator接口，但 Go 中更自然的协作方式是函数回调或 channel 通信 - 最终你会发现：这个接口只被一个 struct 实现，且所有方法都在同一包内调用——那接口纯属冗余
用函数字段替代中介者接口更符合 Go 习惯
把“通知逻辑”作为字段注入，而不是抽象成接口。组件之间不依赖中介者类型，只依赖具体行为：
type ChatRoom struct {
onMessage func(user string, msg string)
}
func (c *ChatRoom) Broadcast(user, msg string) {
if c.onMessage != nil {
c.onMessage(user, msg)
}
}
// 使用时直接传闭包，逻辑内聚、类型安全、无额外抽象
room := &ChatRoom{}
room.onMessage = func(user, msg string) {
log.Printf("[%s] %s", user, msg)
// 这里可以更新 UI、写 DB、推 WebSocket……
}
room.Broadcast("alice", "hello")
- 避免接口层、避免类型断言、避免
interface{}传递 - 测试时可轻松替换
onMessage为 mock 函数 - 如果后续需要多个响应者，改用
[]func(...)或chan即可，无需改接口
当状态协调变复杂时，用 struct + channel 显式建模
真正需要“中介者”语义的场景，往往是多个 goroutine 协作（如聊天室成员管理、游戏房间同步、工作流状态机）。这时应显式封装状态和通信机制，而非模拟 OOP 的“对象间解耦”：
《PHP设计模式》首先介绍了设计模式，讲述了设计模式的使用及重要性，并且详细说明了应用设计模式的场合。接下来，本书通过代码示例介绍了许多设计模式。最后，本书通过全面深入的案例分析说明了如何使用设计模式来计划新的应用程序，如何采用PHP语言编写这些模式，以及如何使用书中介绍的设计模式修正和重构已有的代码块。作者采用专业的、便于使用的格式来介绍相关的概念，自学成才的编程人员与经过更多正规培训的编程人员
立即学习“go语言免费学习笔记（深入）”；
type Room struct {
users map[string]*User
updates chan updateEvent // 类型安全的事件通道
mu sync.RWMutex
}
type updateEvent struct {
Kind string // "join", "leave", "msg"
User *User
Msg string
}
func (r *Room) Run() {
for e := range r.updates {
switch e.Kind {
case "join":
r.mu.Lock()
r.users[e.User.ID] = e.User
r.mu.Unlock()
case "msg":
// 广播给所有在线用户（可加过滤逻辑）
}
}
}
-
updateEvent是具体类型，不是interface{}或string -
Run()方法明确表达了“中介逻辑”的生命周期和边界 - 所有状态变更走
updates通道，天然串行、可追溯、易调试 - 外部调用方只需
room.updates ，无须知道内部如何处理
真正的难点不在“怎么套模式”，而在于判断：当前逻辑是否真的需要一个中心协调点？还是只是把几个函数拆开命名、再用一个空接口粘起来？Go 的简洁性，恰恰来自克制地拒绝抽象。
