设计模式学习笔记--桥接模式(详细笔记)

1. 概述

使用背景：

菜鸟教程

• 在有多种可能会变化的情况下，用继承会造成类爆炸问题，扩展起来不灵活。
• 实现系统可能有多个角度分类，每一种角度都可能变化。把这种多角度分类分离出来，让它们独立变化，减少它们之间耦合。

定义：

《大话设计模式》

桥接模式（Bridge)，将抽象部分与它的实现部分分离，使它们都可以独立地变化。

《图说设计模式》

桥接模式(Bridge Pattern)：将抽象部分与它的实现部分分离，使它们都可以独立地变化。它是一种对象结构型模式，又称为柄体(Handle and Body)模式或接口(Interface)模式。

**类型：**结构型

结构：

《大话设计模式》

《深入设计模式》

适用场景：

菜鸟教程

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

《图说设计模式》

• 如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的继承联系，通过桥接模式可以使它们在抽象层建立一个关联关系。

• 抽象化角色和实现化角色可以以继承的方式独立扩展而互不影响，在程序运行时可以动态将一个抽象化子类的对象和一个实现化子类的对象进行组合，即系统需要对抽象化角色和实现化角色进行动态耦合。

• 一个类存在两个独立变化的维度，且这两个维度都需要进行扩展。

• 虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。

• 对于那些不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统，桥接模式尤为适用。

• 如果你想要拆分或重组一个具有多重功能的庞杂类 （例如能与多个数据库服务器进行交互的类）， 可以使用桥接模式。

  • 类的代码行数越多， 弄清其运作方式就越困难， 对其进行修改所花费的时间就越长。 一个功能上的变化可能需要在整个类范围内进行修改， 而且常常会产生错误， 甚至还会有一些严重的副作用。
  • 桥接模式可以将庞杂类拆分为几个类层次结构。 此后， 你可以修改任意一个类层次结构而不会影响到其他类层次结构。 这种方法可以简化代码的维护工作， 并将修改已有代码的风险降到最低。

• 如果你希望在几个独立维度上扩展一个类， 可使用该模式。

  • 桥接建议将每个维度抽取为独立的类层次。 初始类将相关工作委派给属于对应类层次的对象， 无需自己完成所有工作。

• 如果你需要在运行时切换不同实现方法， 可使用桥接模式。

  • 当然并不是说一定要实现这一点， 桥接模式可替换抽象部分中的实现对象， 具体操作就和给成员变量赋新值一样简单。

实现方式：

1. 明确类中独立的维度。 独立的概念可能是： 抽象/平台， 域/基础设施， 前端/后端或接口/实现。
2. 了解客户端的业务需求， 并在抽象基类中定义它们。
3. 确定在所有平台上都可执行的业务。 并在通用实现接口中声明抽象部分所需的业务。
4. 为你域内的所有平台创建实现类， 但需确保它们遵循实现部分的接口。
5. 在抽象类中添加指向实现类型的引用成员变量。 抽象部分会将大部分工作委派给该成员变量所指向的实现对象。
6. 如果你的高层逻辑有多个变体， 则可通过扩展抽象基类为每个变体创建一个精确抽象。
7. 客户端代码必须将实现对象传递给抽象部分的构造函数才能使其能够相互关联。 此后， 客户端只需与抽象对象进行交互， 无需和实现对象打交道。

优点：

《图说设计模式》

• 分离抽象接口及其实现部分。
• 桥接模式有时类似于多继承方案，但是多继承方案违背了类的单一职责原则（即一个类只有一个变化的原因），复用性比较差，而且多继承结构中类的个数非常庞大，桥接模式是比多继承方案更好的解决方法。
• 桥接模式提高了系统的可扩充性，在两个变化维度中任意扩展一个维度，都不需要修改原有系统。
• 实现细节对客户透明，可以对用户隐藏实现细节。

《深入设计模式》

• 你可以创建与平台无关的类和程序。
• 客户端代码仅与高层抽象部分进行互动，不会接触到平台的详细信息。
• 开闭原则。 你可以新增抽象部分和实现部分， 且它们之间不会相互影响。
• 单一职责原则。 抽象部分专注于处理高层逻辑， 实现部分处理平台细节。

缺点：

《图说设计模式》

• 桥接模式的引入会增加系统的理解与设计难度，由于聚合关联关系建立在抽象层，要求开发者针对抽象进行设计与编程。

• 桥接模式要求正确识别出系统中两个独立变化的维度，因此其使用范围具有一定的局限性。

《深入设计模式》

• 对高内聚的类使用该模式可能会让代码更加复杂。

使用注意：

与其他设计模式的联系：

《图说设计模式》

• 桥接模式和适配器模式用于设计的不同阶段，桥接模式用于系统的初步设计，对于存在两个独立变化维度的类可以将其分为抽象化和实现化两个角色，使它们可以分别进行变化；而在初步设计完成之后，当发现系统与已有类无法协同工作时，可以采用适配器模式。但有时候在设计初期也需要考虑适配器模式，特别是那些涉及到大量第三方应用接口的情况。

《深入设计模式》

• 桥接模式通常会于开发前期进行设计， 使你能够将程序的各个部分独立开来以便开发。 另一方面， 适配器模式通常在已有程序中使用， 让相互不兼容的类能很好地合作。

• 桥接、 状态模式和策略模式 （在某种程度上包括适配器） 模式的接口非常相似。 实际上， 它们都基于组合模式——即将工作委派给其他对象， 不过也各自解决了不同的问题。 模式并不只是以特定方式组织代码的配方， 你还可以使用它们来和其他开发者讨论模式所解决的问题。

• 你可以将抽象工厂模式和桥接搭配使用。 如果由桥接定义的抽象只能与特定实现合作， 这一模式搭配就非常有用。 在这种情况下， 抽象工厂可以对这些关系进行封装， 并且对客户端代码隐藏其复杂性。

• 你可以结合使用生成器模式和桥接模式： 主管类负责抽象工作， 各种不同的生成器负责实现工作。

《图解设计模式》

• Template Method模式(第3章)

  • 为了能够根据需求设计出良好的ConcreteImplementor角色，有时我们会使用AbstractFactory模式。

• Abstract Factory模式(第8章)

  • 在Template Method模式中使用了“类的实现层次结构”。父类调用抽象方法，而子类实现抽象方法。

• Adapter模式(第2章)

  • 使用Bridge模式可以达到类的功能层次结构与类的实现层次结构分离的目的，并在此基础上使这些层次结构结合起来。而使用Adapter模式则可以结合那些功能上相似但是接口(API)不同的类。

识别方法： 桥接可以通过一些控制实体及其所依赖的多个不同平台之间的明确区别来进行识别。

2. 使用实例

菜鸟教程

• 猪八戒从天蓬元帅转世投胎到猪，转世投胎的机制将尘世划分为两个等级，即：灵魂和肉体，前者相当于抽象化，后者相当于实现化。生灵通过功能的委派，调用肉体对象的功能，使得生灵可以动态地选择。
• 墙上的开关，可以看到的开关是抽象的，不用管里面具体怎么实现的。

《图说设计模式》

• 如果需要开发一个跨平台视频播放器，可以在不同操作系统平台（如Windows、Linux、Unix等）上播放多种格式的视频文件，常见的视频格式包括MPEG、RMVB、AVI、WMV等。现使用桥接模式设计该播放器。
• 一个Java桌面软件总是带有所在操作系统的视感(LookAndFeel)，如果一个Java软件是在Unix系统上开发的，那么开发人员看到的是Motif用户界面的视感；在Windows上面使用这个系统的用户看到的是Windows用户界面的视感；而一个在Macintosh上面使用的用户看到的则是Macintosh用户界面的视感，Java语言是通过所谓的Peer架构做到这一点的。Java为AWT中的每一个GUI构件都提供了一个Peer构件，在AWT中的Peer架构就使用了桥接模式

《重学 Java 设计模式》

• 同类服务的不同接口适配包装、同类物料不同组合的建造、多种奖品组合的营销工厂等等

• 

《深入设计模式》

journaldev.com

• java.lang.StringBuilder#append() (unsynchronized)
• java.lang.StringBuffer#append() (synchronized)