设计模式之桥接模式
2021 algorithm桥接模式，也叫桥梁模式，英文名称是 Bridge Design Pattern。
由于某些类型的固有实现逻辑，使得它们具有两个变化的维度，乃至多个维度的变化。如何应对这种“多维度的变化”？如何利用面向对象技术来使得类型可以轻松的沿着两个乃至多个方向变化，而不引入额外的复杂度？
定义
- 在 GoF 的《设计模式》是这样子定义的：将抽象和实现解耦，让它们可以独立变化。
- 另一个定义：一个类存在两个（或多个）独立变化的维度，我们可以通过组合的方式，让这两个（或多个）维度可以独立进行扩展。
对于第一种 GoF 的理解方式，弄懂定义中“抽象”和“实现”两个概念，是理解它的关键。定义中的“抽象”，指的并非“抽象类”或“接口”，而是被抽象出来的一套“类库”，它只包含骨架代码，真正的业务逻辑需要委派给定义中的“实现”来完成。而定义中的“实现”，也并非“接口的实现类”，而是一套独立的“类库”。“抽象”和“实现”独立开发，通过对象之间的组合关系，组装在一起。
对于第二种理解方式，它非常类似“组合优于继承”设计原则，通过组合关系来替代继承关系，避免继承层次的指数级爆炸。
结构
图片来源：维基百科
要点总结
Bridge 模式使用“对象间的组合关系”解耦了抽象与实现之间的固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。所谓抽象和实现沿着各自的维度变化，即“子类化”它们。
Bridge 模式有时候类似于多继承方案，但是多继承方案往往违背单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge 模式是比多继承方案更好的解决方案。
Bridge 模式的应用一般在“两个非常强的变化维度”，有时一个类也有多于两个变化维度，这时可以使用 Bridge 的扩展模式。