如何使用Golang构建桥接模式_Golang桥接模式解耦实现技巧

桥接模式在Go中通过组合+接口字段实现抽象与实现的彻底分离。Abstraction为持Implementor接口字段的struct,RefinedAbstraction增强功能而不改变绑定,具体实现仅实现接口且不知上层存在。

桥接模式在 Go 里不是靠抽象类或接口继承来“模拟”,而是用组合 + 接口字段直接持有实现,核心是把“抽象”和“实现”两根线彻底分开,各自演化互不牵扯。

为什么 Go 不需要传统桥接模式的继承结构

Go 没有类、没有继承、也没有抽象类,所以照搬 Java/C++ 的桥接写法只会让代码变重、变绕。真正的解耦关键在于:抽象层只依赖接口,实现层只实现接口,中间靠字段组合连接

  • Abstraction 是一个 struct,内部持有一个 Implementor 接口类型的字段
  • RefinedAbstraction 是对 Abstraction 的增强(比如加缓存、加日志),不改变其与实现的绑定方式
  • 所有具体实现(如 ConcreteImplementorA)只实现 Implementor 接口,完全不知道上层抽象的存在

标准桥接结构的 Go 实现示例

以“消息发送”为例:发送逻辑(推送/邮件/SMS)和渠道策略(立即发/延时发/重试发)要正交组合。

type Sender interface {
	Send(content string) error
}

type DeliveryStrategy interface {
	Deliver(s Sender, content string) error
}

type MessageService struct {
	sender Sender
	strategy DeliveryStrategy
}

func (m *MessageService) Send(content string) error {
	return m.strategy.Deliver(m.sender, content)
}

// 具体实现
type SMSSender struct{}
func (s SMSSender) Send(content string) error {
	println("SMS:", content)
	return nil
}

type DelayedStrategy struct{}
func (d DelayedStrategy) Deliver(s Sender, content string) error {
	println("Delaying...")
	return s.Send(content)
}

使用时自由组合:ms := &MessageService{sender: SMSSender{}, strategy: DelayedStrategy{}} —— 抽象(MessageService)和实现(SMSSender / DelayedStrategy)完全独立编译、测试、替换。

容易踩的坑:别把接口塞进接口

常见错误是定义一层又一层嵌套接口,比如:

  • 错误:让 DeliveryStrategy 接口方法接收 interface{ Send(string) error } —— 这会让实现无法内联、增加类型断言开销
  • 错误:给 MessageServiceSetSender(Sender)SetStrategy(DeliveryStrategy) 方法,导致运行时才绑定,失去编译期检查和可读性
  • 正确做法:字段在初始化时注入,接口定义窄而稳定(只暴露必要方法),避免“为扩展而扩展”

什么时候该用桥接,而不是简单封装或函数选项

桥接模式的价值只在两个维度都存在**多变且需独立演进**时才凸显:

  • 多个发送方式(SMS / Email / Push) × 多个投递策略(Direct / Batch / Retry) → 共 3×3=9 种组合,用桥接可写 3+3=6 个类型,而非 9 个具体实现
  • 如果只有 1–2 种策略,或策略逻辑极简(如只是加个 time.Sleep),直接用函数参数或结构体字段更轻量
  • 若策略

    间共享大量状态(如共用连接池、上下文),桥接反而会迫使你在每个 Implementor 里重复管理,此时应考虑用策略模式 + 共享依赖注入

真正难的是识别出哪部分该划为“抽象轴”,哪部分该划为“实现轴”——这没法靠模式名称判断,得看业务变化频率和团队协作边界。