17370845950

桥接模式在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 } —— 这会让实现无法内联、增加类型断言开销
• 错误：给 MessageService 加 SetSender(Sender) 和 SetStrategy(DeliveryStrategy) 方法，导致运行时才绑定，失去编译期检查和可读性
• 正确做法：字段在初始化时注入，接口定义窄而稳定（只暴露必要方法），避免“为扩展而扩展”

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

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

• 多个发送方式（SMS / Email / Push） × 多个投递策略（Direct / Batch / Retry） → 共 3×3=9 种组合，用桥接可写 3+3=6 个类型，而非 9 个具体实现
• 如果只有 1–2 种策略，或策略逻辑极简（如只是加个 time.Sleep），直接用函数参数或结构体字段更轻量
• 若策略间共享大量状态（如共用连接池、上下文），桥接反而会迫使你在每个 Implementor 里重复管理，此时应考虑用策略模式 + 共享依赖注入

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