桥梁模式

定义： 将抽象部分与它的实现部分分离， 使他们都可以独立地变化。这里的抽象部分和实现部分不是我们通常认为的父类与子类、接口与实现类的关系，而是组合关系。

桥梁模式由4种角色组成：

抽象角色：       它定义了抽象类的接口而且维护着一个指向实现角色的引用。

精确抽象角色： 实现并扩充由抽象角色定义的接口。

实现角色：       给出了实现类的接口，这里的接口与抽象角色中的角色可以不一致。

具体实现角色： 给出了实现角色定义接口的具体实现。

简单理解： 就是一个抽象接口A里有另一个抽象接口B作为成员变量，通过这个B的方法去实现A本身的方法。 各自有各自的实现类。

参考代码：

//抽象部分（前端）的抽象角色
class Abstraction {
    //维护着一个指向实现（Implementor）角色的引用
   private Implementation implementation;
    public Abstraction(Implementation imp) {
    implementation = imp;
    }
    // 下面定义了前端（抽象部分）应该有的接口
    public void service1() {
    //使用了后端（实现部分）已有的接口
    //组合实现功能
    implementation.facility1();
    implementation.facility2();
    }
    public void service2() {
    implementation.facility2();
    implementation.facility3();
    }
    public void service3() {
    implementation.facility1();
    implementation.facility2();
    implementation.facility4();
    }
    // For use by subclasses:
    protected Implementation getImplementation() {
    return implementation;
    }
}
//抽象部分（前端）的精确抽象角色
class ClientService1 extends Abstraction {
    public ClientService1(Implementation imp) { super(imp); }
    //使用抽象角色提供的方法组合起来完成某项功能
    //这就是为什么叫精确抽象角色（修正抽象角色）
    public void serviceA() {
    service1();
    service2();
    }
    public void serviceB() {
    service3();
    }
}
//另一个精确抽象角色，和上面一样的被我省略了
class ClientService2 extends Abstraction {
    。。。。
    //这里是直接通过实现部分的方法来实现一定的功能
    public void serviceE() {
    getImplementation().facility3();
    }
}
//实现部分（后端）的实现角色
interface Implementation {
    //这个接口只是定义了一定的接口
    void facility1();
     void facility2();
     void facility3();
    void facility4();
}
//具体实现角色就是要将实现角色提供的接口实现
//并完成一定的功能
//这里省略了
class Implementation1 implements Implementation {
。。。

使用环境与优势
由上面我们分析得来的桥梁模式，可以看出来桥梁模式应该适用于以下环境：
1) 当你的系统中有多个地方要使用到类似的行为，或者是多个类似行为的组合时，可以考虑使用桥梁模式来提高重用，并减少因为行为的差异而产生的子类。
2) 系统中某个类的行为可能会有几种不同的变化趋势，为了有效的将变化封装，可以考虑将类的行为抽取出来。
3) 当然上面的情况也可以是这样，行为可能要被不同相似类使用，也可以考虑使用桥梁模式来实现。桥梁模式使用了低耦合性的组合代替继承，使得它具备了不少好处：
                        1) 将可能变化的部分单独封装起来，使得变化产生的影响最小，不用编译不必要的代码。
                        2) 抽象部分和实现部分可以单独的变动，并且每一部分的扩充都不会破坏桥梁模式搭起来架子。
                        3) 对于客户程序来说，你的实现细节是透明的。