如何使用Golang实现桥接模式_Golang桥接模式接口分离方法

桥接模式在Go中通过接口定义行为契约、结构体字段组合实现解耦，而非传统继承；Shape与Renderer接口互不依赖，Circle等类型持Renderer实例委托绘制，确保运行时可任意替换渲染器实现。

桥接模式在 Go 里根本不用“实现”，而是靠接口和组合自然达成

Go 没有类继承，也不支持抽象类或“桥接抽象与实现”的传统 UML 建模方式。所谓“Golang 实现桥接模式”，其实是用 interface 定义行为契约，用结构体字段持有具体实现（即组合），让抽象部分（如 Renderer）和实现部分（如 WindowsRenderer、LinuxRenderer）解耦。这不是模拟设计模式，而是 Go 的惯用法。

定义清晰的接口：抽象层和实现层各一个 interface

关键不是写多少结构体，而是把职责切开。比如图形渲染场景：

• Shape 接口只声明 Draw()，不关心怎么画
• Renderer 接口只声明 RenderLine()、RenderPoint() 等底层能力，不关心画什么
• 两者之间**不互相依赖**，Shape 内部持有一个 Renderer 实例来委托绘制

错误做法是让 Shape 直接调用 WindowsRenderer.DrawLine() —— 这就又紧耦合了。

结构体组合实现桥接：用字段而非嵌入

组合时明确使用字段名（如 r Renderer），而不是匿名嵌入（Renderer）。后者容易模糊边界，导致误调用实现细节。

type Circle struct {
    x, y, r float64
    r       Renderer // 显式命名，强调“我用你，但我不属于你”
}

func (c *Circle) Draw() {
    c.r.RenderCircle(c.x, c.y, c.r) // 委托给 renderer，不暴露 renderer 类型
}

注意：Circle 不需要知道 c.r 是 *OpenGLRenderer 还是 *SVGRenderer，只要它满足 Renderer 接口即可。

避免常见陷阱：别在接口里塞实现细节

容易踩的坑包括：

• 把平台相关类型（如 syscall.Handle、*C.GdkWindow）放进 Renderer 接口方法签名里 —— 这会让接口无法跨平台实现
• 让 Shape 实现 Renderer 接口（即“自己画自己”）—— 违反桥接初衷，失去替换渲染器的能力
• 用 func 类型代替 interface 来做“桥接”—— 虽然能跑，但丧失类型安全和可扩展性（比如没法加新方法）
• 在 NewCircle(r Renderer) 构造函数里对 r 做类型断言（if w, ok := r.(*WindowsRenderer)）—— 直接破坏桥接效果

桥接是否生效，就看能不能在运行时任意替换 Renderer 实现而不改 Shape 代码。做不到这点，就只是写了两个无关结构体而已。