Golang中介者模式实现与模块通信方案

本文深入剖析了在 Go 语言中盲目套用经典中介者模式的危害，指出其极易引发接口臃肿、循环导入和依赖隐晦等反模式问题；转而倡导更符合 Go 简洁哲学的替代方案——通过函数值显式注入实现松耦合通信、用轻量事件总线支持多对多广播，并强调真正的协调逻辑应下沉到 main 层或初始化代码中，由开发者主动掌控依赖流向而非隐藏在抽象接口之后；全文以实战代码为例，清晰展示了如何写出易测试、易维护、无隐式依赖的地道 Go 风格模块通信方案。

Go 语言没有类继承和接口强制实现机制，也不鼓励通过复杂对象图来协调模块通信——所以直接照搬经典中介者模式（Mediator Pattern）到 Go 中，大概率会写出难测试、难维护的“Java 风”代码。

为什么 Mediator 接口在 Go 里容易变成反模式

经典中介者依赖一个中心接口（如 Mediator），让同事类（Colleague）持有该接口引用并调用其方法。但在 Go 中：

• Mediator 接口一旦定义过宽，就会迫使所有实现暴露不相关的函数，违背接口最小化原则
• 同事类型若通过字段持有 Mediator，会导致循环导入（比如 user.go 引用 mediator.go，而后者又需导入 user.go 的类型）
• 运行时靠接口动态分发行为，掩盖了真实依赖流向，单元测试时难以 mock 或替换

用函数值 + 显式注入替代中介者接口

把“中介逻辑”降级为普通函数，由创建方决定谁响应什么事件，不引入中间抽象层。

例如两个模块 UserManager 和 NotificationService 需在用户注册后发通知：

type UserManager struct {
	onUserCreated func(userID string)
}

func (u *UserManager) Register(name string) string {
	userID := generateID()
	// ... 保存用户
	if u.onUserCreated != nil {
		u.onUserCreated(userID)
	}
	return userID
}

type NotificationService struct{}

func (n *NotificationService) SendWelcomeEmail(userID string) {
	fmt.Printf("sent welcome to %s\n", userID)
}

组装时显式连接：

notif := &NotificationService{}
mgr := &UserManager{
	onUserCreated: func(id string) { notif.SendWelcomeEmail(id) },
}

• 零接口、零循环导入、依赖一目了然
• 测试时可传入闭包断言行为：onUserCreated: func(id string) { assert.Equal(t, "u123", id) }
• 扩展新响应者只需改调用点，不修改 UserManager 结构定义

需要多对多广播？用 map[string][]func() 或第三方事件总线

当事件源与响应者数量增长，手动绑定变得冗长。此时可轻量封装一个发布-订阅结构，但避免过度设计：

type EventBus struct {
	handlers map[string][]func(interface{})
}

func (e *EventBus) Subscribe(eventType string, f func(interface{})) {
	e.handlers[eventType] = append(e.handlers[eventType], f)
}

func (e *EventBus) Publish(eventType string, data interface{}) {
	for _, f := range e.handlers[eventType] {
		f(data)
	}
}

使用时仍保持控制权在初始化侧：

bus := &EventBus{handlers: make(map[string][]func(interface{}))}
bus.Subscribe("user.created", func(data interface{}) {
	notif.SendWelcomeEmail(data.(string))
})
mgr := &UserManager{eventBus: bus}

• 不导出全局单例，每个业务上下文可拥有独立事件总线
• 事件类型用字符串而非常量，降低耦合；若需类型安全，可用泛型封装（Go 1.18+）
• 注意：不要在 Publish 中 recover panic，否则会掩盖 handler 内部错误

真正该警惕的是“隐式中介者”

比刻意实现中介者更危险的，是那些没命名、没封装、却承担中介职责的代码块：

• 在 HTTP handler 里直接调用数据库、缓存、邮件服务、日志上报 —— 它成了事实上的中介，但没人能复用或替换单个环节
• 一个巨型 service.go 文件里塞了所有业务逻辑跳转，靠 if/else 分发请求 —— 这不是中介者，这是无名上帝对象

中介的本质不是“加一层”，而是“明确谁负责协调、谁负责执行”。Go 的惯用法是把协调逻辑写在 main 包或 cmd 层，用函数组合或结构体字段注入来表达关系——而不是发明一个叫 Mediator 的新抽象。

以上就是《Golang中介者模式实现与模块通信方案》的详细内容，更多关于的资料请关注golang学习网公众号！