Golang中介者模式提升模块解耦效果

一分耕耘，一分收获！既然打开了这篇文章《Golang中介者模式优化模块耦合》，就坚持看下去吧！文中内容包含等等知识点...希望你能在阅读本文后，能真真实实学到知识或者帮你解决心中的疑惑，也欢迎大佬或者新人朋友们多留言评论，多给建议！谢谢！

中介者模式在Go中通过struct+interface+闭包解耦模块，避免类型引用；用channel和统一Event消息实现轻量协调；中介仅路由、转换、缓冲，不承载业务逻辑，确保删除模块时不需修改其他模块导入或构造函数。

中介者模式在 Go 中的核心作用是解耦通信双方

Go 本身没有类继承和接口强制实现机制，但中介者模式依然有效——关键不是“如何模仿 Java 写法”，而是用 struct + interface + 闭包或回调函数，把原本直接调用的依赖关系，转为通过一个中间对象协调。真正降低耦合的不是模式本身，而是你是否让模块之间不再持有对方的类型引用。

用 channel 和 interface 实现轻量中介者

Go 的并发模型天然适合中介者：模块不互相调用，而是向中介发送消息、从中介接收响应。避免使用全局变量或单例，每个中介实例应可独立生命周期管理。

• 定义统一消息类型，比如 type Event struct{ Type string; Payload interface{} }
• 中介者持有一组 map[string]func(Event) 处理器，按 Type 分发
• 模块只依赖中介的接口（如 Mediator interface{ Notify(Event); Register(string, func(Event)) }），不关心具体实现
• 注册时用匿名函数包装模块方法，避免暴露内部结构体字段

type SimpleMediator struct {
	handlers map[string][]func(Event)
}

func (m *SimpleMediator) Notify(e Event) {
	for _, h := range m.handlers[e.Type] {
		h(e)
	}
}

func (m *SimpleMediator) Register(t string, f func(Event)) {
	m.handlers[t] = append(m.handlers[t], f)
}

警惕“伪中介者”：别让中介变成上帝对象

常见错误是把所有逻辑都塞进中介者，导致它既处理业务又转发事件，最终比原来更难维护。中介者只做三件事：路由、转换、缓冲（可选）。业务规则仍应在模块内部。

• 不要在中介里写 if e.Type == "order_created" { sendEmail(); updateInventory() }
• 不要让中介持有数据库连接、HTTP 客户端等具体依赖
• 如果两个模块通信频率极高（如高频状态同步），考虑是否真需要中介——直接 channel 配对可能更清晰
• 测试中介者时，用 mock handler 替代真实模块，验证事件是否被正确分发

与 Go 生态协同：用 context 和 error 统一传递上下文

原生 context.Context 和 error 不应被中介者截断。模块发出的 Event 可嵌入 ctx context.Context 字段；中介分发前应检查 ctx.Err() 并跳过已取消操作；所有 handler 返回的 error 应透传回发起方，而不是吞掉或转成 panic。

耦合度是否真的降低了，不看代码行数，而看当你删掉某个模块时，是否还需要修改其他七八个模块的 import 列表或构造函数参数——中介者存在的唯一意义，就是让这个删除动作变得安静。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。