Golang中介者模式：简化通信降低耦合

本文深入探讨了中介者模式在Go语言中的自然落地实践，通过结构体、接口与组合而非继承来构建灵活的通信协调机制：以ChatRoom等具体中介者封装多对象交互逻辑，使同事对象（如User）仅依赖Mediator接口、通过Notify统一中转消息，彻底消除彼此间的直接引用和紧耦合；同时借助Go的轻量抽象与依赖注入特性，轻松实现中介者替换、单元测试模拟及并发安全扩展——当系统交互规则日益复杂（如加入权限校验、异步分发或日志审计），所有变更只需聚焦中介者内部，各协作组件保持稳定，真正让设计模式服务于可维护性与演进力。

在 Go 语言中，中介者模式（Mediator Pattern）不是靠继承或接口强制实现的“框架式”设计，而是通过一个中心化的协调者（Mediator）来封装多个对象（Colleague）之间的交互逻辑，从而避免对象间直接引用和紧耦合。Go 没有类和继承，但完全可以用结构体、接口和函数组合自然地表达这一思想——关键是把“谁和谁通信”的决策从参与者中抽离出来，交给一个明确的中介者负责。

定义清晰的 Mediator 接口与具体实现

先抽象出中介者行为：它需要能接收消息、识别发送方/接收方、并触发相应处理。不依赖具体类型，只依赖约定好的方法签名。

例如：

type Mediator interface {
    Notify(sender interface{}, event string, data interface{})
}

type ChatRoom struct {
    users map[string]User
}

func (c *ChatRoom) Notify(sender interface{}, event string, data interface{}) {
    switch event {
    case "join":
        c.broadcast(sender, "new user joined")
    case "message":
        c.broadcast(sender, data.(string))
    }
}

func (c *ChatRoom) broadcast(exclude interface{}, msg string) {
    for _, u := range c.users {
        if u != exclude {
            u.Receive(msg)
        }
    }
}

这里 ChatRoom 是具体中介者，它不关心用户具体是什么类型，只通过 User 接口的 Receive 方法通信。

让协作对象只依赖 Mediator 接口，不互相引用

每个“同事”（如 User）持有 Mediator 的引用，但不持有其他同事的引用。它的所有对外动作都通过中介者中转。

定义同事接口：

type User interface {
    Send(event string, data interface{})
    Receive(msg string)
    SetMediator(m Mediator)
}

具体实现只需关注自身职责：

type ConcreteUser struct {
    name     string
    mediator Mediator
}

func (u *ConcreteUser) Send(event string, data interface{}) {
    u.mediator.Notify(u, event, data) // 不知道谁会响应，只通知中介者
}

func (u *ConcreteUser) Receive(msg string) {
    fmt.Printf("[%s] received: %s\n", u.name, msg)
}

func (u *ConcreteUser) SetMediator(m Mediator) {
    u.mediator = m
}

这样，User A 和 User B 完全解耦：A 不需要知道 B 的存在，也不需要调用 B 的任何方法。

用组合代替硬编码，灵活替换中介逻辑

Go 中推荐用字段组合而非继承，所以中介者实例通常作为结构体字段注入。这便于测试和替换——比如开发时用内存版 ChatRoom，上线后换成带 Redis 广播的 DistributedChatRoom。

• 初始化时注入：user.SetMediator(&ChatRoom{users: make(map[string]User)})
• 单元测试可传入 mock Mediator，断言 Notify 是否被正确调用
• 不同场景可实现不同 Mediator：审批流中介者、设备联动中介者、事件总线简化版等

注意 Go 特性带来的实践差异

Go 没有构造器重载或自动生命周期管理，所以要注意几点：

• 中介者若需维护状态（如用户列表），确保并发安全——加 sync.RWMutex 或用 sync.Map
• 避免循环引用：User 持有 Mediator，Mediator 又持有 User 切片 → 这本身没问题，但释放资源时需主动清理（如登出时从中介者中移除）
• 不用为“松耦合”过度抽象：如果只有两个对象且通信极简单，直接传函数回调可能比引入 Mediator 更轻量

中介者模式的价值不在“用了设计模式”，而在于当交互规则变复杂（比如加权限校验、消息过滤、异步分发、日志审计）时，你只需修改中介者，所有同事对象保持不变。

今天关于《Golang中介者模式：简化通信降低耦合》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！