共计 2800 个字符，预计需要花费 7 分钟才能阅读完成。
Bridge（桥接模式）
Bridge（桥接模式）属于结构型模式，是一种解决继承后灵便拓展的计划。
用意：将形象局部与它的实现局部拆散，使它们能够独立地变动。
桥接模式比拟难了解，我会一步步还原该设计模式的思考，让你领会这个设计模式是如何一步一步被提炼进去的。
举例子
如果看不懂下面的用意介绍，没有关系，设计模式须要在日常工作里用起来，联合例子能够加深你的了解，上面我筹备了三个例子，让你领会什么场景下会用到这种设计模式。
汽车生产线革新为新能源生产线
汽油车与新能源汽车的生产流程有很大相似之处，那么汽油车生产线是否疾速革新为新能源汽车生产线呢？
如果汽油车生产线没有将外部实现解耦，只把生产汽油车的各局部独立了进去，对新能源车生产线是没什么用途的，但如果汽油车生产线提供了更底层的能力，比方加装轮胎，加装方向盘，那么这些步骤是能够同时被汽油车与新能源车所共享的。
在设计汽油车生产线时，就将生产过程与汽油车解耦，使其能够疾速使用到新能源汽车的生产，这就是桥接模式的一种使用。
窗口（Window）类的派生
假如存在一个 Window 窗口类，其底层实现在不同操作系统是不一样的，假如对于操作系统 A 与 B，别离有 AWindow 与 BWindow 继承自 Window，当初要做一个新性能 ManageWindow（管理器窗口），就要针对操作系统 A 与 B 别离生成 AManageWindow 与 BManageWindow，这样显然不容易拓展。
无论咱们新增反对 C 操作系统，还是新增反对一个 IconWindow，类的数量都会成倍晋升，因为咱们所做的 AMangeWindow 与 BMangeWindow 同时存在两个即以上的独立维度，这使得减少维度时，代码变得很冗余。
适配多个搭建平台的物料
做前端搭建平台时，经常出现一些物料（组件）因为固化了某个搭建平台的 API，因而无奈迁徙到另一个搭建平台，如果要迁徙，就须要为不同的平台写不同的组件，而这些组件中大部分 UI 逻辑都是一样的，这使得产生大量代码冗余，如果再兼容一个新搭建平台，或者为已有的 10 个搭建平台再创立一个新组件，工作量都是写一个组件的好几倍。
用意解释
用意：将形象局部与它的实现局部拆散，使它们能够独立地变动。
“形象”局部与“实现”局部拆散，这句话看起来很像接口与实现。的确，如果“形象”指的是 接口 (Interface)，而“实现”指的是 类 (Class) 的话，这就是简简单单的 class MyWindow implements Window 类实现过程而已。
但后半句话“使它们能够独立地变动”会让你难以和前半句分割起来，如果说“形象”不变，“实现”能够随便扭转还好了解，但反过来就难以解释了。
其实桥接模式中，形象指的是一种接口（Abstraction），实现指的也是一种接口（Implementor），其中 Implementor 并不是间接实现了 Abstraction 定义的接口，而是提供更底层的办法，使 Abstraction 能够基于它们封装出本人的接口实现。
这样一来，Abstraction 的接口能够随便变动，毕竟调用的是 Implementor 提供函数的组合，只有 Implementor 提供的性能全面，Implementor 能够不变；相应的，Implementor 的实现也能够随便变动，只有提供的底层函数不变，就不影响 Abstraction 对其的应用。
下面举的三个例子都是这样，咱们应该把汽油车生产线的规范与通用汽车生产线规范拆散、将具体性能窗口与适配不同操作系统的根底 GUI 能力隔离、将组件性能与平台性能隔离，只有做到了形象局部与实现局部的隔离，才能够通过组合满足更多场景。
结构图
- Abstraction：定义抽象类的接口。
- RefinedAbstraction：裁减 Abstraction。
- Implementor：定义实现类的接口，该接口能够与 Abstraction 接口不统一。
- ConcreteImplementor：实现 Implementor 接口并定义它的具体实现。
形象局部就是 Abstraction，实现局部就是 Implementor，在这个结构图中，它们是拆散的，能够各自独立变动的，桥接模式，就是指 imp 这个桥，通过 Implementor 实现 Abstraction 接口，就算是桥接上了，这种组合的桥接相比一般的类实现更灵便，更具备拓展性。
代码例子
对于完全版桥接模式，Implementor 能够有多套实现，Abstraction 不需关怀具体用的是哪一种实现，而是通过形象工厂形式封装。上面举一个简略版的例子。
上面例子应用 typescript 编写。
`class Window {
private windowImp: WindowImp
public drawBox() {
// 通过画线生成 box
this.windowImp.drawLine(0, 1)
this.windowImp.drawLine(1, 1)
this.windowImp.drawLine(1, 0)
this.windowImp.drawLine(0, 0)
}
}
// 拓展 window 就非常容易
class SuperWindow extends Window {
public drawIcon {
// 通过自定义画线
this.windowImp.drawLine(0, 5)
this.windowImp.drawLine(3, 9)
}
}
`
桥接模式的精华，通过下面的例子能够这么了解：
Window 的能力是 drawBox，那继承 Window 容易拓展 drawIcon 吗？默认是不行的，因为 Window 并没有提供这个能力。经剖析能够看出，划线是一种根底能力，不应该与 Window 代码耦合，因而咱们将根底能力放到 windowImp 中，这样 drawIcon 也能够利用其根底能力画线了。
弊病
不要适度形象，桥接模式是为了让类的职责更繁多，保护更便捷，但如果只是个小型我的项目，桥接模式会减少架构设计的复杂度，而且不正确的模块拆分，把原本关联的逻辑强制解耦，在将来会导致更大的问题。
另外桥接模式也有简略与简单模式之分，只有一种实现的场景就不要用形象工厂做适度封装了。
总结
桥接模式让咱们从新扫视类的设计是否正当，把类中不相干，或者说互相独立的维度抽出去，由桥接模式做桥接的形式应用，这样会使每个类性能更内聚，代码量更少更清晰，组合能力更弱小，更容易做拓展。
下图做了一个简略的解释：
探讨地址是：精读《设计模式 – Bridge 桥接模式》· Issue #280 · dt-fe/weekly
如果你想参加探讨，请 点击这里，每周都有新的主题，周末或周一公布。前端精读 – 帮你筛选靠谱的内容。
关注 前端精读微信公众号
版权申明：自在转载 - 非商用 - 非衍生 - 放弃署名（创意共享 3.0 许可证）
