Golang如何设计并实现中介者模式_Golang中介者模式详解

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 的“对象间解耦”：

立即学习“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 的简洁性，恰恰来自克制地拒绝抽象。