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

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

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

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")
}