设计模式-Bridge

Bridge:桥接设计模式

用意：
【GOF95】在提出桥梁模式的时候指出，桥梁模式的用意是"将抽象化(Abstraction)与实现化(Implementation)脱耦，使得二者可以独立地变化"。这句话有三个关键词，也就是抽象化、实现化和脱耦。

抽象化：存在于多个实体中的共同的概念性联系，就是抽象化。作为一个过程，抽象化就是忽略一些信息，从而把不同的实体当做同样的实体对待【LISKOV94】。
实现化:抽象化给出的具体实现，就是实现化。
脱耦:所谓耦合，就是两个实体的行为的某种强关联。而将它们的强关联去掉，就是耦合的解脱，或称脱耦。在这里，脱耦是指将抽象化和实现化之间的耦合解脱开，或者说是将它们之间的强关联改换成弱关联。

将两个角色之间的继承关系改为聚合关系，就是将它们之间的强关联改换成为弱关联。因此，桥梁模式中的所谓脱耦，就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以相对独立地变化。这就是桥梁模式的用意。


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

结构：
系统含有两个以上等级结构：抽象化角色和修正抽象化角色组成的抽象化等级结构。等级结构意味着不同层面的两个分级，往往通过一个等级持有另外一个等级的实例，实现组合的效果。

抽象化(Abstraction)角色：抽象化给出的定义，并保存一个对实现化对象的引用。
修正抽象化(Refined Abstraction:扩充抽象类)角色：扩展抽象化角色，改变和修正父类对抽象化的定义。（可以有多个修正抽象化角色，根据客户端的需要）
实现化(Implementor)角色：这个角色给出实现化角色的接口，但不给出具体的实现。必须指出的是，这个接口不一定和抽象化角色的接口定义相同，实际上，他们毫无关系。实现化角色应当只给出底层操作，而抽象化角色应当只给出基于底层操作的更高一层的操作。
具体实现化(Concrete Implementor)角色：这个角色给出实现化角色接口的具体实现。

JDK的使用场景：
java.util.logging中的Handler和Formatter




桥接模式的结构图：




例子：
要求：输出一副带有颜色的图形

分析：
多个维度：颜色维度，图形维度
组合：两个维度组合来实现任意的颜色画任意的图形

拓展：
新的维度：比如新增人，分为：儿童/成人

要求：
儿童画一副带有红色的圆圈

颜色维度：

/**
 * @author xinchun.wang
 */
public interface Color {
   public String getColor();
}


public class Red implements Color {

	public String getColor() {
		return "red";
	}

}

public class Green implements Color {

	public String getColor() {
		return "green";
	}

}

图形维度：（图本语义上就应该有颜色）

public abstract class Shape {

	protected Color color;

	public abstract void draw();

	public void setColor(Color color) {
		this.color = color;
	}
	
}

public class Line extends Shape {

	public void draw() {
		System.out.println("draw " + color.getColor() + " line");
	}

}

public class Circle extends Shape {

	public void draw() {
		System.out.println("draw " + color.getColor() + " Circle");
	}

}

测试代码：

public class Context {
	public static void main(String[] args) {
		Color red = new Red();
		Shape line = new Line();
		line.setColor(red);
		line.draw();

		Shape circle = new Circle();
		circle.setColor(red);
		circle.draw();

	}
}

说明：这样实现仅仅有了 Color，Green，Red，Shape，Circle，Line 六个类，如果新增一种颜色，也就再添加一个类即可，同样之于图形，如果是通过继承就需要m(颜色种类) * n（图型）个类。

下面有个题目考察桥接模式：
现欲实现一个图像浏览系统，要求该系统能够显示BMP、JPEG和GIF三种格式的文件，并且能够在Windows和Linux两种操作系统上运行。系统首先将BMP、JPEG和GIF三种格式的文件解析为像素矩阵，然后将像素矩阵显示在屏幕上。系统需具有较好的扩展性以支持新的文件格式和操作系统。为满足上述需求并减少所需生成的子类数目，采用桥接(Bridge)设计模式进行设计所得类图如图7-1所示。



采用该设计模式的原因在于：系统解析BMP、JPEG与GIF文件的代码仅与文件格式相关，而在屏幕上显示像素矩阵的代码则仅与操作系统相关。

class Matrix {  //各种格式的文件最终都被转化为像素矩阵
   //此处代码省略
}
 
interface ImageImp {
   public void doPaint(Matrix m);  //显示像素矩阵m
}
 
class WinImp implements ImageImp {
   public void doPaint(Matrix m) {/*调用Windows系统的绘制函数绘制像素矩阵*/}
}
 
class LinuxImp implements ImageImp {
   public void doPaint(Matrix m) {/*调用Linux系统的绘制函数绘制像素矩阵*/}
}
 
abstract class Image {
   public void setImp(ImageImp imp) {
            (1)      = imp; }
   public abstract void parseFile(String fileName);
   protected      (2)        imp;
}
 
class BMP extends Image {
   public void parseFile(String fileName) {
       //此处解析BMP文件并获得一个像素矩阵对象m
                  (3)            ;//显示像素矩阵m
    }
}
 
class GIF extends Image {
   //此处代码省略
}
 
class JPEG extends Image {
   //此处代码省略
}
 
public class Main{
   public static void main(String[] args)
    {
       //在Windows操作系统上查看demo.bmp图像文件
       Image image1 =      (4)      ;
       ImageImp imageImp1 =       (5)      ;
                  (6)            ;
       image1.parseFile("demo.bmp");
    }
}
 
       现假设该系统需要支持10种格式的图像文件和5种操作系统，不考虑类Matrix，若采用桥接设计模式则至少需要设计         （7）         ____个类

分析与解答：

本题是桥接模式的一个应用实例，在本实例所述系统中，存在文件格式和操作系统两个独立变化的维度，这两个维度都需要独立进行扩展和维护，因此可以使用桥接模式来进行设计与实现。
       在本实例的类图中，抽象图像文件类Image充当Abstraction（抽象类），具体图像文件类BMP、GIF和JPEG充当RefinedAbstraction（扩充抽象类），ImageImp充当Implementor（实现类接口），而两种不同操作系统的实现类WinImp和LinuxImp充当ConcreteImplementor（具体实现类）。
       根据桥接模式的实现原理，在抽象类Image中维持了一个对实现类接口ImageImp类型对象的引用，正因为在两个维度的抽象层之间存在一个高层的关联关系，其形状类似一条桥，“桥接模式”故此得名。因此，第(2)空为实现类接口ImageImp。在程序运行时，可以通过构造方法或者Setter方法将一个实现ImageImp接口的子类对象注入到Image对象中，但是在定义的时候仍使用ImageImp作为传入参数的类型，根据里氏代换原则，任何ImageImp的子类对象都可以在运行时覆盖由ImageImp定义的对象，不难得知，第(1)空为给ImageImp类型的成员变量imp赋值，答案为this->imp【C++】或this.imp【Java】，此处使用的是Setter注入。
       根据实例说明，系统解析BMP、JPEG与GIF文件的代码仅与文件格式相关，而在屏幕上显示像素矩阵的代码则仅与操作系统相关，在获得一个特定格式的像素矩阵之后，在不同的操作系统中其显示程序有所不同，因此需要调用ImageImp 子类的doPaint()方法来显示像素矩阵，第(3)空略有难度，根据多态和里氏代换原则，ImageImp子类对象在运行时才注入，而在代码中统一使用ImageImp类型的imp来编程实现，这体现了“依赖倒转原则”，即针对抽象（接口）编程，而不针对具体编程。由此可知，第(3)空为调用imp对象的显示像素矩阵方法doPaint()来显示图像【注意方法的参数】，答案为imp -> doPaint(m)【C++】或imp.doPaint(m)【Java】。
      第(4)-(6)空考查客户端代码的编写，由于在代码注释中已经明确指出“在Windows操作系统上查看demo.bmp图像文件”，因此图像文件的格式为BMP类型，且显示在Windows操作系统中，我们只需从两个维度中选择对应的具体类，并实例化成对象，然后将对象进行组合即可。image1的类型为BMP，imageImp1的类型为WinImp，第(4)空用于创建一个BMP类型的图像对象，而第(5)空用于创建一个WinImp类型的对象。第(6)空需要仔细考虑，该空用于将对象进行组合，即将对象imageImp1注入到对象image1中，答案为image1 -> setImp(imageImp1)【C++】或image1.setImp(imageImp1)。
      最后一空考查桥接模式对整个系统设计的影响，要求计算使用桥接模式之后系统中类的个数。桥接模式的优点之一就是避免类的个数出现爆炸式增长，减少类的个数。如果不使用桥接模式而使用多层继承结构，具体类的个数为两个维度类型数目的乘积，而使用桥接模式之后，具体类的个数仅为两个维度类型数目之和。因此当系统需要支持10种格式的图像文件和5种操作系统时（不考虑类Matrix），如果采用桥接模式，只需要 10 + 5 = 15个具体类，再加上两个抽象层类，至少需要设计17个类；如果不采用桥接模式，而使用多层继承，则所需的具体类数目为 10 * 5 = 50个，再加上各种抽象层和中间层的类，类的个数要远远超过17个，因此，桥接模式的引入将简化系统设计，减少系统中类的个数，并使得系统扩展起来更加灵活。

其他参考：
http://blog.csdn.net/jason0539/article/details/22568865
http://blog.csdn.net/humanbeng/article/details/7897554