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分离开来。