桥梁模式

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

桥梁模式由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) 对于客户程序来说,你的实现细节是透明的。

 

原文地址:https://www.cnblogs.com/chenyao/p/3026068.html