菜鸟学设计模式系列笔记之Bridge模式

“依赖倒置原则”：抽象不应该依赖于实现细节，实现细节应该依赖于抽象

Intent ：将抽象部分与它的实现部分分离，使它们都可以独立第变化

Motivation：

（1）要做到“抽象（接口）与实现分离”，最常用的方法是定义一个抽象类，然后在子类中提供实现。

也就是说用继承机制达到“抽象（接口）与实现分离”

（2）但是这种方法不够灵活，继承机制把实现与抽象部分永久地绑定起来，要想独立地修改、扩展、重用抽象（接口）与实现都非常困难



Abstraction 定义抽象类的接口；维护一个指向Implementor类型对象的指针

RefinedAbstraction 扩充由Abstraction 定义的接口

Implementor 定义实现类的接口，不一定要与Absrtraction的接口完全一致，甚至可以完全不同的

ConcreteImplementor 实现Implementor接口并定义它的具体实现 

分离接口及其实现部分。抽象类的实现可以在运行时刻进行配置，一个对象甚至可以在运行时刻改变它的实现

提高可扩充性：抽象与实现两部分可以单独扩充

实现细节对客户透明

一般来说，一个继承结构中的第一层是抽象角色，封装了抽象的商业逻辑，这是系统中不变的部分；

第二层是实现角色，封装了设计中会变化的因素。这个实现允许实现化角色有多态性变化

使用两个独立的等级结构封装两个独立的变化因素，并在它们之间使用聚合关系，以达到功能复合的目的。使用桥接模式。抽象化与实现化的变化分别得到封装之后，使用聚合关系联系抽象化角色和实现化角色



一个好的设计通常没有多于两层的继承等级结构。如果出现两个以上的变化因素，就需要找出哪一个因素是静态的，可以使用继承关系；哪一个动态的，必须使用聚合关系；桥接模式是“对变化的封装”原则以及合成、聚合复用原则的极好例子



（1）Bridge 模式使用“对象间的组合对象”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化

（2）抽象和实现沿着各自的维度变化，即“子类化”它们，得到不同的子类后，便可以任意组合它们

（3）Bridge模式有时类似于多继承方案，但是多继承方案往往违背单一职责原则，复用性较差。

（4）Bridge 模式应用一般在两个非常强的变化维度，有时应用中即使有两个变化的维度，但在某个方向的变化维度并不剧烈——即两个变化不会导致纵横交错的结果，并不一定使用bridge模式

Abstract Factory可以用来创建和配置Bridge模式

与Adapter模式的区别：

Adapter模式用来帮助无关的类协同工作，通常在系统设计完成之后才会被使用

Bridge模式则在系统开始时就被使用，他使得抽象接口和实现部分可以独立进行改变