桥梁模式

Decoople an abstraction from its implementation so that the two can vary independently.
将抽象和实现解耦，使得两者可以独立地变化。

桥梁模式的通用类图

桥梁模式的通用源码

• 实现化角色

  public interface Implementor {
  
      //基本方法
      public void doSomething();
      public void doAnything();
  }
  

• 具体实现化角色1

  public class ConcreteImplementor1 implements Implementor {
  
      @Override
      public void doSomething() {
          //业务逻辑
      }
  
      @Override
      public void doAnything() {
          //业务逻辑
      }
  
  }
  

• 具体实现化角色2

  public class ConcreteImplementor2 implements Implementor {
  
      @Override
      public void doSomething() {
          //业务逻辑
      }
  
      @Override
      public void doAnything() {
          //业务逻辑
      }
  
  }
  

• 抽象化角色

  public abstract class Abstraction {
  
      //定义对现实化角色的引用
      private Implementor impl;
      //约束子类必须实现该构造函数
      public Abstraction(Implementor _impl) {
          this.impl = _impl;
      }
      //自身的行为和属性
      public void request() {
          this.impl.doSomething();
      }
      //获得实现化角色
      public Implementor getImpl() {
          return impl;
      }
  }
  

• 修正抽象化角色

  public class RefinedAbstraction extends Abstraction {
  
      public RefinedAbstraction(Implementor _impl) {
          super(_impl);
      }
  
      //修正父类的行为
      @Override
      public void request() {
          super.request();
          super.getImpl().doAnything();
      }
  
  }
  

• 场景类

  public class Client {
  
      public static void main(String[] args) {
          //定义一个实现化角色
          Implementor impl = new ConcreteImplementor1();
          //定义一个抽象化角色
          Abstraction abs = new RefinedAbstraction(impl);
          //执行
          abs.request();
      }
  }
  

桥梁模式的优点

• 抽象和实现分离。完全是为了解决继承的缺点而提出的设计模式，在桥梁模式下，实现可以不受抽象的约束，不用再绑定在一个固定的抽象层次上。
• 优秀的扩充能力
• 实现细节得客户透明

桥梁模式的使用场景

• 不希望或不适合使用继承的场景。
• 接口或者抽象类不稳定的场景。
• 重用性要求较高的场景。