必知必会的设计模式2

桥接模式（Bridge Pattern）

属结构型设计模式，也称桥梁模式，「将抽象和实现解耦，使得两者可以独立地变化」

桥接模式的重点在于解耦，为的就是解决继承带来的缺点。例如在多层继承的情况下，改动就会变得很困难，甚至牵一发而动全身，为了满足需求就必须解耦。重构的重点就在于分离出抽象和实现两部分，通过抽象部分持有实现部分的引用，从而完成桥接关联。这样抽象部分的子类实现与实现部分的子类实现就可以解耦，相互独立变化。

桥接模式.jpg

对于「抽象部分」和「实现部分」的定义，书中没有明确给出，但大致可以这么规定，持有另一方对象引用的就是抽象部分，它所做的是一种行为规范，明确做什么这一类的事，而实现部分是指具体怎么做。

另外，和「装饰模式」相比较，如果抽象装饰类不继承自功能抽象类，那么就可以演变为「桥接模式」了，可见模式与模式间的转换可以很灵巧，无非是针对某个场景得出的一种解决方案。

优缺点

• 抽象和实现解耦
• 易扩充
• 实现细节封装透明

使用场景

• 接口或抽象类变动可能性较大
• 重用性较高的场景，例如多个子类继承实现的情况

在 Android 中的使用

在「Android 进阶解密」书中的第 191 页说到 WindowManagerImpl 将部分功能实现交给成员变量 WindowManagerGlobal 来实现，使用了桥接模式。但按书本资料描述的桥接模式定义，感觉有点不像，如果是这样的，那我觉得可能这么来理解，即抽象部分的子类（WindowManagerImpl）持有实现部分子类（WindowManagerGlobal）引用，并且实际的增，删，更新窗口是由 WindowManagerGlobal 来实现的。这样理解的话，我觉得倒像是桥接模式的广义定义，即 A 类持有 B 类的引用，并且实际通过 B 类对象来完成部分功能。

不过，在 WMS 相关的内容这块确实能找到桥接模式的应用，例如 Window 类是个抽象类，其内部有一个 WindowManager 类型的变量。 PhoneWindow 继承自 Window，是具体的实现子类。WindowManagerImpl 实现了 WindowManager 接口，负责 Window 相关的操作。那么这里就是桥接模式的体现，Window 作为抽象部分，WindowManager 作为实现部分，我看是蛮标准的桥接模式。

我们自己在实现桥接模式时，要抓住唯一的重点：解耦。

参考内容

「设计模式之禅（第 2 版）」
「Android 源码设计模式解析与实战」