如何在Golang中实现中介者模式_Golang中介者模式对象交互示例

Go中无法照搬UML类图的中介者模式，因其缺乏类继承且易引发循环导入、nil panic和并发安全问题；应改用接口+回调函数+chan等原生机制解耦，同事仅暴露事件钩子，中介者通过注册回调协调交互。

Go 语言没有类和继承，也不支持传统面向对象意义上的“中介者模式”实现（比如用抽象中介者 + 具体中介者 + 各种同事类继承体系），但可以用接口、函数值、结构体组合和通道等原生机制达成等效效果——关键是解耦对象间的直接引用，让交互通过一个中心协调者转发。

为什么 Go 里不能照搬 UML 类图的中介者模式

标准中介者模式依赖：同事对象持有中介者引用、中介者持有所有同事引用、同事之间不直接通信。Go 中若强行模拟，容易出现循环导入（colleague.go 引 mediator.go，后者又引回前者）、指针管理混乱、测试困难等问题。

实际可行的做法是：用 interface{} 或更具体的回调函数类型替代“同事抽象类”，用结构体字段存储可变行为，用 chan 或闭包控制时序和响应边界。

常见错误现象：

• 把 *Mediator 塞进每个同事结构体，导致初始化顺序错乱或 nil panic
• 在中介者方法里直接调用同事的导出方法，又反过来让同事调中介者，形成隐式循环依赖
• 用全局变量存中介者实例，破坏可测试性和并发安全性

用函数字段 + 接口实现轻量中介协调

核心思路：同事不持有中介者，只暴露事件钩子（如 OnMessage、OnChange）；中介者通过设置这些钩子来注入逻辑，同事触发时自动通知中介者，中介者再决定调用谁。

适用场景：UI 组件联动（如按钮点击更新列表+禁用输入框）、微服务间弱一致性通知、配置变更广播等不需要强状态同步的交互。

示例中，User 和 Logger 都实现 Notifier 接口，ChatMediator 不持有它们的指针，而是接收它们注册的回调函数：

type Notifier interface {
    Notify(event string, data interface{})
}

type ChatMediator struct {
  
  onUserJoin func(username string)
    onMessage  func(sender, msg string)
}

func (m *ChatMediator) RegisterUserJoin(f func(string)) {
    m.onUserJoin = f
}

func (m *ChatMediator) RegisterMessage(f func(string, string)) {
    m.onMessage = f
}

type User struct {
    name string
    notify func(event string, data interface{})
}

func (u *User) Send(msg string) {
    u.notify("message", map[string]string{"sender": u.name, "msg": msg})
}

func main() {
    mediator := &ChatMediator{}
    
    logger := &Logger{}
    user1 := &User{name: "Alice", notify: func(e string, d interface{}) {
        if e == "message" {
            data := d.(map[string]string)
            mediator.onMessage(data["sender"], data["msg"])
        }
    }}
    
    mediator.RegisterMessage(func(sender, msg string) {
        logger.Log(sender + ": " + msg)
        if sender == "Alice" && msg == "/ban" {
            // 这里可以触发其他协作逻辑，比如通知 moderator
        }
    })
    
    user1.Send("Hello")
}

用 channel 实现异步中介通信（适合高并发）

当同事间交互有明确生产者/消费者关系，且需解耦执行时机（比如日志写入不阻塞业务逻辑），用 chan 更自然。中介者变成消息路由中心，不主动调用同事，只转发事件。

性能影响：channel 有缓冲开销，但避免了锁和 goroutine 泄漏风险；若用无缓冲 channel，要注意发送方是否可能被阻塞。

关键点：

• 每个同事只向中介者的 input chan 发送结构化事件（不要传指针或闭包）
• 中介者用 select 多路复用，按事件类型分发到不同处理逻辑
• 同事从自己的 output chan 读响应，避免中介者反向调用造成耦合

错误典型：在中介者里直接 go colleague.Handle(...)，结果同事结构体未实现并发安全，或 handle 方法 panic 导致整个中介 goroutine 退出。

什么时候该放弃“模式名”，直接用简单函数或 map 注册

如果同事数量固定（≤3）、交互逻辑简单（如 A 改变 → B 更新 → C 刷新）、且生命周期短（如 CLI 工具的一次性流程），硬套中介者反而增加理解成本。

更 Go 的做法是：

• 定义一个协调函数，参数是各组件的接口或函数类型：func RunChat(ui UI, log Logger, db DB)
• 用 map[string]func() 存事件处理器，key 是事件名，value 是匿名函数，内部闭包捕获所需依赖
• 测试时直接传 mock 函数，不用构造整套结构体树

复杂点在于：事件命名易冲突、缺乏类型检查、重构时不易发现调用链断裂。这些比“不符合设计模式”更值得警惕。