[toc]
为什么要用桥接#
假设希望设计一个补数据接口类Downloader，用于向其他服务器同步数据。 对外提供一个接口
download()
最开始以为只需要同步不同类型的数据即可， 那么只要实现
DataADownloader、 DataBDownloader这几种即可。
但是到后来， 发现不仅要在下载数据中选择， 还可能要选择补数据的方式。
比如有的服务希望是异步download
有的服务是希望加密download
如果只是简单增加类型，则可能出现
AsyncDataADownloader
AsyncDataBDownloader
EncryptDataADownloader
EncryptDataBDownloader
当你发现你不断实现的子类 出现了功能在不同层次叠加的情况，就要注意用桥接模式，做不同层次接口的桥接，而不是只用一个接口导致子类爆炸增长。
桥接方式#
用 成员的方式进行桥接。
把功能A类型接口作为成员，桥接进另一个功能B类型的抽象类中， 另一个功能的抽象方法只要考虑如何调用这个成员即可。
补数据的场景如下所示：
桥接模式优点：#
- 解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。
抽象和实现不再在同一个继承层次结构中，而是“子类化”它们，使它们各自都具有自己的子类，以便任何组合子类，从而获得多维度组合对象 - 桥接模式可以取代多层继承方案（例如刚才的另一种解决方案可能是多重继承2个接口），多层继承方案违背了“单一职责原则”，复用性较差，且类的个数非常多，桥接模式是比多层继承方案更好的解决方法，它极大减少了子类的个数
- 提高了系统的可扩展性，在两个变化维度中任意扩展一个维度，都不需要修改原有系统，符合“开闭原则”
桥接模式的缺点#
- 增加系统的理解与设计难度，由于关联关系建立在抽象层，要求开发者一开始就针对抽象层进行设计与编程
- 要求正确识别出系统中两个独立变化的维度，因此其使用范围具有一定的局限性，如何正确识别两个独立维度也需要一定的经验积累。
因此缺点主要在设计难度上。
其他案例： 知乎：用点咖啡来讲解桥接模式