Bridge模式

一 意图

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

　　（类设计的开闭原则：对扩展开放，对修改关闭）

二 动机

　　看看文章中的例子：可移植的window的抽象部分的实现，及其扩展的方式

　　　　1 如需增加新的类型window就必须要重新增加新的window类，

　　且仍然要区分对应平台的window类型，如果要是新增加一个平台，那整个结构都需要重新添加新的window类型。

　　　　2 继承机制使得客户代码与平台相关。XWindow对象的实现方式仅支持在XWindow平台上运行，包括其所扩展的对象，

　　都只能在XWindow平台上运行，如果要在PMWindow上实现，代码不能共享，需要重新移植。

　　　　3 依赖性太强，没有将仅对平台依赖的部分独立开来，而是不断的扩展不断的依赖平台。

　　解决此问题的方法就是：将对平台依赖的部分独立出来——将window与平台相关的实现部分分离出来，

　　提供相关的抽象接口和具体平台相关的实现类。

　　将逻辑接口抽象为Window，将具体平台实现抽象为WindowImp。

　　将复杂的类继承依赖关系结构转变为组合结构的依赖关系。

三 适用性和结构

         1 使抽象和实现部分之间没有固定的的绑定关系

         2 类的抽象和实现都通过它的子类来完成和加以扩充。使得不同的抽象和实现进行任意组合。

         3 隐藏实现部分；对抽象部分或者实现部分修改不影响其他部分。

结构

 

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

 

　　Implementor定义实现类的接口，并不一定要与Abstraction接口一致，

仅仅是实现类所必需的接口。Abstraction提供的是高层次的接口。

将接口和实现分离，解决这种依赖性关系所带来的系统扩展，代码复用，系统层次结构问题。

四 代码实现

以动机中window为例

1 Impementor

2 Implementor Creator

3  Abstrction和RefinedAbstraction

4 Test

5 Result

 

五 实例分析

　　动态列表数据加载形式：动态列表会包含不确定的大量的数据；

获取数据的方式形式多样并不能保持总是同步方式，还需要实时的更新；数据的存储位置等。

1 简单基本形式

　　ListMenu提高一系列设置ListMenu数据属性的接口，由客户端自行去设置而不由系统来维护。

这种实际上就是一种同步的形式，只有数据Ready然后将数据传递给ListMenu。

2 使用Bridge模式

　　这是工作平台上实现方式，是所有使用到列表的地方都要ListMenuContentProvider继承下来类，

既作为客户端也作为具体映射实现。虽然具有统一性，但是感觉怪怪的。

3 使用Bridge模式

将Client和ConcreteImplementor分离开来。