设计模式（十二）桥模式（Bridge）-结构型

桥模式Bridge引文

根据面向对象的设计原则,应该尽量使用组合而不是继承。桥模式将抽象与其实现解耦，使他们可以分别独立地变化，是继承的一种代替方式。
对于两个类之间需要进行关联时，不要直接在一个类的代码中调用另一个类的代码，而是要通过这些设计模式，在两个类之间建立一个类似的缓冲器的类，从而将直接关联的两个类进行解耦，以保证以后当一个类的接口发生变化时不会影响另一个类的使用。

实现原理图

桥模式实现原理图

实现代码

实现类接口的示意代码如下：

public interface Implement {
    void operation1();
}

抽象类的示意代码如下：

public abstract class Interface {
    Implement impl;
    public Interface(Implement impl){
        this.impl = impl;
    }
    public void operation1(){
        this.impl.operation1();
    }
}

抽象类的继承类的示意代码如下：

public class Interface1 implements Interface {
    public Interface1(Implement impl){
        super(impl);
    }
    public void operation1(){
        impl.operation1();
    }
}

抽象类的另一个继承类：

public class Interface2 implements Interface {
    public Interface2(Implement impl){
        super(impl);
    }
    public void operation1(){
        impl.operation1();
    }
}

实现类的继承类的示意代码如下：

public class Implement1 implements Implement {
    public void operation1(){
    }
}

实现类的另一个继承类的示意代码如下：

public class Implement1 implements Implement {
    public void operation1(){
    }
}

现实应用

销售电脑案例
电脑可分为：台式、笔记本、平板电脑；
还可以分为不同的品牌：戴尔、苹果、联想等；
如何设计类才算合理？

桥梁模式的优点

• 抽象和实现分离
  这是桥梁模式的主要特点，它完全是为了解决继承的缺点而提出的设计模式。在该模式下，实现可以不受抽象的约束，不用再绑定在一个固定的抽象层次上。
• 优秀的扩展能力
• 实现细节对客户透明
  客户不用关心细节的实现，它已经由抽象层通过聚合关系完成了封装。

桥梁模式的使用场景

• 不希望或不适用使用继承的场景
  例如继承层次过渡、无法更细化设计颗粒等场景，需要考虑使用桥梁模式。
• 接口或抽象类不稳定的场景
  明知道接口不稳定还想通过实现或继承来实现业务需求，那是得不偿失的，也是比较失败的做法。
• 重用性要求较高的场景
  设计的颗粒度越细，则被重用的可能性就越大，而采用继承则受父类的限制，不可能出现太细的颗粒度。

桥梁模式的注意事项

• 使用桥梁模式时主要考虑如何拆分抽象和实现，并不是一涉及继承就要考虑使用该模式，那还要继承干什么。
• 桥梁模式的意图还是对变化的封装，尽量把可能变化的因素封装到最细、最小的逻辑单元中，避免风险扩散。
• 系统设计时，发现类的继承有N层时，可以考虑使用桥梁模式。