Golang桥接模式如何分离抽象与实现_结构拆分思路

桥接模式在Go中通过组合+接口实现抽象与实现分离：抽象层为持有接口字段的struct，实现层为实现该接口的具体类型，接口方法仅描述行为而不绑定具体实现。

Golang桥接模式如何分离抽象与实现_结构拆分思路第1张

桥接模式在 Go 中没有抽象类，怎么建模抽象与实现的分离

Go 不支持继承和抽象类，所以不能照搬 Java/C++ 的桥接模式 UML 图。关键不是“模仿结构”，而是守住桥接的核心意图：让 抽象层 和 实现层 可以独立变化、互不绑定。实际做法是用组合 + 接口，把“抽象”定义为一个持有实现接口的结构体，而“实现”是一组满足该接口的具体类型。

抽象层 是一个 struct，内嵌或持有某个接口字段（比如 renderer Renderer）
实现层 是一组各自实现该接口的 struct（比如 VectorRenderer、RasterRenderer）
抽象方法内部不写具体逻辑，只调用接口方法（如 b.renderer.DrawCircle(x, y, r)）

抽象结构体要不要暴露实现接口字段

不建议直接暴露接口字段（如公开 Renderer 字段），否则使用者可能绕过抽象逻辑直接调用实现，破坏封装。应该把接口字段设为私有，并通过构造函数注入，同时提供可选的默认实现。

type Shape struct {
    renderer Renderer // 小写首字母，包外不可见
}

func NewShape(r Renderer) *Shape {
    if r == nil {
        r = &RasterRenderer{} // 默认实现
    }
    return &Shape{renderer: r}
}

外部无法修改 renderer 字段，避免状态错乱
构造时传入不同实现，即可切换渲染方式，不影响 Shape 其他方法
如果需要运行时切换，可加一个 SetRenderer(r Renderer) 方法，但要确保线程安全（如加锁或仅用于初始化阶段）

实现接口的方法签名设计容易踩哪些坑

接口方法参数过多、或包含具体类型（如 *svg.Document），会绑架所有实现，失去桥接意义。接口应只描述“做什么”，不规定“怎么做”或“用什么工具做”。

❌ 错误示例：DrawCircle(doc *svg.Document, x, y, r float64) —— 强制所有实现都依赖 svg 包
✅ 正确方向：DrawCircle(x, y, r float64) —— 坐标和半径是通用语义，各实现自行决定如何转成矢量指令或像素填充
若需传递上下文（如颜色、缩放），应抽成独立结构体（如 Style），而非具体三方类型

为什么桥接比策略模式更适合“多维度变化”的场景

策略模式聚焦于“同一件事的不同算法”，比如排序有快排/归并；桥接则解决“两个正交变化轴”的耦合问题——比如图形类型（Circle、Square） × 渲染方式（Raster、Vector）。如果硬用策略，你会被迫为每种组合写一个策略（RasterCircle、VectorCircle……），数量爆炸。