设计模式之桥梁(Bridge)

桥梁模式是对象的结构模式，又称柄体(Handle and Body)模式或接口(Interface)模式。
    桥梁模式的用意是 "将抽象化(Abstraction)与实现化(Implementation)脱耦，使得二者可以独立地变化"。
    by kyo：抽象化有其单独的等级结构，实现化有其单独的等级结构，两者相不互干扰。
    抽象化：存在于多个实体中共同的的概念性联系，就是抽象化。作为一个过程，抽象化就是忽略一些信息，从而把不同的实体当作同样的实体对待。
    实现化：抽象化的具体实现，就是实现化，一个类的实例就是这个类的实现化，一个具体子类是它的抽象超类的实现化。
    脱耦：所谓耦合，就是两个实体的行为的某种强关联。而将它们的强关联去掉，就是耦合的脱耦。
    所谓强关联，就是在编译时期已经确定的，无法在运行时期动态改变的关联。所谓弱关联，就是可以动态地确定并且可以在运行时期动态地改变的关联。显然， 在 Java 语言中，继承关系是强关联，而聚合关系是弱关联。
    桥梁模式中所谓的脱耦，就是指一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以相对独立地变化。这就是所谓的桥梁模式。
   
    继承是一种强耦合，它在一开始便把抽象化角色和实现化角色的关系绑定(binding)，使得两个层次之间相互限制，无法独立的演化。
   
    桥梁模式的角色：
    抽象化(Abstraction)角色：抽象化给出的定义，并保存一个对实现化对象的引用。
    修正抽象化(Refined Abstraction)角色：扩展抽象化角色，改变和修正父类对抽象化的定义。
    实现化(Implementor)角色：这个角色给出实现化角色的接口，但不给出具体的实现。必须指出的是，这个接口不一定和抽象化角色的接口定义相同。实际上，这两个接口可以非常不一样。实现化角色应当只给出底层操作，而抽象化角色应当只给出基于底层操作的更高一层的操作。
    具体实现化(Concrete Implementor)角色：这个角色给出实现化角色接口的具体实现。
    桥梁模式的等级结构：
    由抽象化角色和修正抽象化本身组成的抽象化等级结构。
    由实现化角色和具体实现化角色所组成的实现化等级结构。
   
    一般而言，实现化角色中的每一个方法都应当有一个抽象化角色中的某个方法与之相对应，但是反过来则不一定。换言之，抽象化角色的接口比实现化角色的接口宽。抽象化角色除了提供与实现化角色相关的方法外，还有可能提供其他的商业方法；而实现化角色则往往仅为实现抽象化角色的相关行为而存在。
    by kyo：抽象化角色不一定是抽象类。如修正抽象化角色有可能不是抽象类。
   
    Java 为 AWT 中的每一个GUI 构件提供了一个 Peer 构件( by kyo：应该是每种操作系统一组 Peer 构件)，这个 Peer 构件是所属的 Java 构件在本地化环境中的实现化。在 Java 的 AWT 库中的每一个 Component 的子类都有一个 ComponentPeer 的子类与之匹配。所有 Component 的子类都属于一个等级结构，而所有的 ComponentPeer 的子类都属于另一个等级结构。Component 类型和 ComponentPeer 类型通过 Toolkit 对象相互通信。Component 相当于抽象角色，其子类如 Button 相当于修正抽象角色；ComponentPeer 相当于实现化角色，而 ButtonPeer 相当于具体实现化角色。系统根据当前操作系统动态地选择 Button 对象所使用的底层实现。Java 的 AWT 就是这样做到 "Write once , run anywhere " 的。
   
    大多数的驱动器(Driver)都是桥梁模式的应用。使用驱动程序的应用系统就是抽象化角色，而驱动器本身扮演实现化角色。这使得应用程序与驱动器可以独立演化。如 JDBC 驱动器，一个应用系统动态地选择一个合适的驱动器，然后通过驱动器向数据库引擎发出指令。这个过程就是将抽象化角色的行为委派给实现角色的过程。
   
    所谓重构，就是在不增加或减少一个软件系统的功能的情况下，对代码的结构进行优化。
    所谓组合/聚合复用原则讲的是要尽量使用合成/聚合，而不是通过继承关系来达到扩展系统功能的目的。
    使用桥梁模式的关键在于准确地找出系统的抽象化角色和具体化角色。 by kyo：分离抽象化与实现化。
    "找到系统的可变因素，将之封装起来" ，通常就叫做 "对变化的封装"。
    一般来说，一个继承结构中的第一层是抽象角色，封装了抽象的商业逻辑，这是系统中不变的部分。第二层是实现角色，封装了设计中会变化的因素。这个实现允许实现化角色有多态性变化。
    桥梁模式将两个独立的等级结构封装在两个独立的变化因素中。抽象化和实现化的变化分别得到封装之后，使用聚合关系联系抽象化角色与实现化角色。以达到功能复用的目的。
    从另一个角度讲，一个好的设计通常没有多于两层的继承等级结构。或者说，如果出现两个以上的变化因素，就需要找出哪一个是静态的，可以使用继承关系，哪一个是动态的，必须使用聚合关系。
   
    桥梁模式和适配器模式的区别：
    适配器模式的目的是要改变已有的接口，让它们可以相容，以使没有关系的两个类能在一起工作。而桥梁模式是分离抽象化和实现化，使得两者的接口可以不同。两个模式是向相反方向努力的。
区别类图相似而本质不同的设计模式的关键是比较两者的用意：一个模式被设计出来要解决的问题，便是此模式的用意。
桥梁模式和状态模式的关系：
桥梁模式描述两个等级结构之间的关系，状态模式则描述一个对象与其(外部化的)状态对象之间的关系。状态对象可以看做是桥梁模式的一个退化后的特殊情况。

在什么情况下应当使用桥梁模式：
如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系。
设计要求实现化角色的任何改变不应当影响客户端，或者说实现化角色的改变对客户端是完全透明的。
一个构件有多于一个的抽象化角色和实现化角色，系统需要它们之间进行动态耦合。
虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。

一个图像格式有两个基本的方面，一是结构，二是表象。其结构决定图像是怎样存储的，而其表象决定了图像是怎样显示在屏幕上的。对于一个图像格式来说，其结构是在任何一种操作系统中都不变的(但不同格式的图像有不同的结构)，而其表象是在每个操作系统中都有所不同的(不同的操作系统有不同的表象)。图像的结构和表现是两个不同的方面，应该让它们独立地变化，桥梁模式正好可以在这里发挥作用。