桥接模式的优缺点是什么？

简化版

桥接模式的优点是解耦抽象和实现、减少类爆炸、提升扩展性和运行时组合灵活性；缺点是增加抽象层次，对维度划分要求高，小场景使用会显得复杂。

详细版

桥接模式最明显的收益是让两个变化维度独立扩展。例如新增一种消息类型不影响发送渠道，新增一种发送渠道也不影响消息类型。

它的代价也很明确：

• 需要额外接口和抽象类。
• 需要先识别变化维度。
• 对初学者来说结构不如直接继承直观。
• 如果拆错维度，会让系统更绕。

所以桥接模式适合变化维度清晰、组合关系会增长的场景，不适合简单固定的小功能。

完整版教学

一、优点：抽象和实现解耦

桥接模式把业务抽象和底层实现分离。抽象侧只依赖实现接口，不依赖具体实现类。

这样做的好处是：业务代码不需要知道底层细节。比如紧急通知不需要知道短信网关参数，也不需要知道邮件服务商 API。

解耦后的系统更容易替换实现，也更容易测试。测试通知逻辑时，可以注入一个假的 Sender，不必真的发送短信。

二、优点：减少组合类

桥接模式可以把类数量从乘法关系降成加法关系。

如果有 4 种抽象类型和 5 种实现方式：

• 继承组合可能需要 20 个组合类。
• 桥接只需要 4 个抽象类或子类，加 5 个实现类。

这个优势在维度持续扩展时非常明显。

三、优点：符合开闭原则

桥接模式让新增功能主要通过新增类完成，而不是修改已有类。

新增发送渠道：

• 增加一个 Sender 实现。
• 不修改已有通知类型。

新增通知类型：

• 增加一个 Notification 子类。
• 不修改已有发送渠道。

这能降低回归风险，尤其适合多人协作和长期维护的系统。

四、优点：运行时组合更灵活

因为桥接模式使用对象组合，所以实现可以在运行时选择。

例如根据用户配置选择短信、邮件或企业微信；根据部署环境选择本地存储或对象存储。这种灵活性是继承层级不容易提供的。

五、缺点：结构更复杂

桥接模式会引入额外的抽象类和接口。对于简单场景，这些结构可能让代码显得啰嗦。

如果项目只有一个通知类型和两个固定渠道，直接写两个服务方法也许更清楚。桥接模式的价值来自未来变化，而不是当前代码行数最少。

六、缺点：维度划分有难度

桥接模式成败取决于维度划分。

如果把业务规则放进实现接口，实现层会越来越臃肿；如果把底层细节放进抽象类，抽象层又会和实现绑定。

错误划分会带来两个后果：

• 接口频繁变化，所有实现类被迫修改。
• 抽象层和实现层互相知道太多，解耦失败。

七、缺点：不适合过度设计

桥接模式需要有明确的扩展压力。如果只是为了套设计模式而提前拆层，代码会变得难读。

实际开发中可以先观察需求是否出现“多维度组合增长”。如果只是短期固定需求，可以先保持简单；当第二个变化维度开始明显出现时，再考虑重构为桥接。

八、常见误区与追问

桥接的主要收益是让两个维度独立扩展，主要代价是抽象层和对象装配增加。若4种业务形态与5种平台组合，继承可能形成20个组合类，桥接通常维护9个核心类型；但只有1×1组合时，额外接口几乎没有回报。判断应基于变化概率，而不是只看当前类数量。

检查维度	判定依据
优势	避免交叉继承，支持运行期组合
代价	类型与委托层增多，设计门槛提高

组合类节省量 = A×B - (A+B)

心法：桥接用“多一层委托”换“两边少互相修改”。

• 误区：桥接一定减少代码行数。 它可能增加接口和装配代码，收益在长期扩展与依赖隔离。
• 追问：性能损耗是否明显？ 一次虚方法委托通常不是瓶颈，真正成本多在理解和维护。
• 误区：维度越多越适合不断桥接。 过多正交接口会导致配置爆炸，应控制稳定边界。
• 追问：如何量化扩展收益？ 比较新增一个维度成员需要修改的类型数和回归范围。
• 追问：最大的设计风险是什么？ 错误识别变化轴，使接口含义模糊并让两侧仍互相泄漏细节。

九、加强记忆

桥接模式的优点来自拆维度，缺点也来自拆维度：拆对了，扩展清爽；拆早了或拆错了，结构就会绕。判断是否使用它，要看组合变化是否真的存在。