12-桥接模式（Bridge）

意图

将抽象部分与它的实现部分分离，使他们可以独立地变化

个人理解

一句话概括就是只要是在抽象类中聚合了某个接口或者抽象类，就是使用了桥接模式。
抽象类A中聚合了抽象类B（或者接口B），A的子类的方法中在相同的场景下调用了B的子类的方法。

动机

该小节摘抄于GOF的《设计模式》
当一个抽象可能有多个实现时，通常用继承来协调它们。抽象类定义对该抽象的接口，而具体的子类则用不同的方式实现。但是此方法有时不够灵活。继承机制将抽象部分与他的实现部分固定在一起，，使得难以对抽象部分和实现部分独立地进行修改、扩充和复用。
假设一个场景：在一个用户界面工具箱中有一个可移植的Window抽象部分的实现。这一抽象部分应该允许用户开发一些在X Window 和IBM的Presentation Manager（PM）系统中都可以使用的应用程序。运用继承机制，我们可以定义一个Window抽象类和它的两个子类Xwindow与PMWindow，由它们分别实现不同系统平台上的Window界面。但是继承机制有两个不足之处：
1）扩展Window抽象使之不适用于不同种类的窗口或新的系统平台很不方便。假设有Window的一个子类IconWindow，它专门将Window抽象用于图标处理。为了使IconWindow支持两个系统平台，我们必须实现连个新类XIconWindow和PMIconWindow，更糟糕的是，我们不得不为每一种类型的窗口都定义两个类。而为了支持第三个系统平台，我们还必须为每一种窗口定义一个新的Window子类，如下图所示。

2）继承机制使得客户代码与平台相关。每当用户创建一个窗口时，必须要实例化一个具体的类，这个类有特定的实现部分。例如，创建XWindow对象会将Window抽象与XWindow的实现部分绑定起来，这使得客户程序依赖于X Window的实现部分。这将使得很难将客户代码移植到其他平台上去。
客户在创建窗口是应该不涉及具体实现部分，仅仅是窗口的实现部分依赖于应用运行的平台。这样客户代码在创建窗口时就不应该涉及特定的平台。
Bridge模式解决以上问题的方法是，将Window抽象和它的实现部分分别放在独立地类层次结构中。其中一个类层次接口针对窗口接口（Window、IconWindow、TransientWindow），另外一个独立地类层次结构针对平台相关的窗口实现部分，这个类层次结构的根类为WindowImp。例如XWindowImp子类中提供了一个基于X Window系统的实现，如下图所示：

使用场景

1. 如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的继承联系，通过桥接模式可以使它们在抽象层建立一个关联关系。
2. 对于那些不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统，桥接模式尤为适用。
3. 一个类存在两个独立变化的维度，且这两个维度都需要进行扩展。
   注意事项：对于两个独立变化的维度，使用桥接模式再适合不过了。

示例讲解

参考尚硅谷的教程：https://www.bilibili.com/video/BV1G4411c7N4?p=68&vd_source=3141b9fdb12c5901aa70919c50575543

实际应用场景

• 在JDBC的源码 Driver类中有体现：https://www.bilibili.com/video/BV1G4411c7N4?p=69&vd_source=3141b9fdb12c5901aa70919c50575543