桥接模式（Bridge Pattern）

模式动机：

设想如果要绘制矩形、圆形、椭圆、正方形，我们至少需要4个形状类，但是如果绘制的图形需要具有不同的颜色，如红色、绿色、蓝色等，此时至少有如下两种设计方案：

1、第一种设计方案是为每一种形状都提供一套各种颜色的版本。

2、第二种设计方案是根据实际需要对形状和颜色进行组合。

 

对于有两个变化维度（即两个变化的原因）的系统，采用方案二来进行设计系统中类的个数更少，且系统扩展更为方便。设计方案二即是桥接模式的应用。桥接模式将继承关系转换为关联关系，从而降低了类与类之间的耦合，减少了代码编写量。

 

模式意图：

桥接模式(BridgePattern)：将抽象部分与它的实现部分分离，使它们都可以独立地变化。它是一种对象结构型模式，又称为柄体(Handle and Body)模式或接口(Interface)模式。

 

UML图：

 

 

角色：

Abstraction：抽象类部分接口。通常在这个对象中，要维护一个实现部分的对象的引用，在抽象对象里面的方法，需要调用实现部分的对象来完成。这个对象中的方法，通常都是和具体的业务相关的方法。

RefinedAbstraction：扩充抽象类。通常在这些对象中，定义跟实际业务相关的方法，这些方法的实现通常会使用Abstraction中定义的方法，也可能需要调用实现部分的对象来完成。

Implementor：实现类接口。这个接口不用和Abstration中的方法一致，通常是由Implementator接口提供基本的操作。而Abstraction中定义的是基于这些基本操作的业务方法，也就是说Abstraction定义了基于这些操作的较高层次的操作。

ConcreteImplementor：真正实现Implemenor接口的对象。

 

模式分析：

代码：

public interface Implementor

{

         publicvoid operationImpl();

}

 

public abstract class Abstraction

{

         protected Implementor impl;

        

         publicvoid setImpl(Implementor impl)

         {

                   this.impl=impl;

         }

        

         publicabstract void operation();

}

 

 

 

优缺点：

优点：

1、分离抽象接口及其实现部分。

桥接模式有时类似于多继承方案，但是多继承方案违背了类的单一职责原则（即一个类只有一个变化的原因），复用性比较差，而且多继承结构中类的个数非常庞大，桥接模式是比多继承方案更好的解决方法。

2、桥接模式提高了系统的可扩充性，在两个变化维度中任意扩展一个维度，都不需要修改原有系统。

3、实现细节对客户透明，可以对用户隐藏实现细节。

 

缺点：

1、桥接模式的引入会增加系统的理解与设计难度，由于聚合关联关系建立在抽象层，要求开发者针对抽象进行设计与编程。

2、桥接模式要求正确识别出系统中两个独立变化的维度，因此其使用范围具有一定的局限性。

 

 

使用范围：

1、如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的继承联系，通过桥接模式可以使它们在抽象层建立一个关联关系。

2、抽象化角色和实现化角色可以以继承的方式独立扩展而互不影响，在程序运行时可以动态将一个抽象化子类的对象和一个实现化子类的对象进行组合，即系统需要对抽象化角色和实现化角色进行动态耦合。

3、一个类存在两个独立变化的维度，且这两个维度都需要进行扩展。

4、虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。

5、对于那些不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统，桥接模式尤为适用。

 

模式扩展：

适配器模式与桥接模式的联用

桥接模式和适配器模式用于设计的不同阶段，桥接模式用于系统的初步设计，对于存在两个独立变化维度的类可以将其分为抽象化和实现化两个角色，使它们可以分别进行变化；而在初步设计完成之后，当发现系统与已有类无法协同工作时，可以采用适配器模式。但有时候在设计初期也需要考虑适配器模式，特别是那些涉及到大量第三方应用接口的情况。

 

转载于:https://www.cnblogs.com/ustc11wj/archive/2012/07/20/2610879.html