7 『桥接模式』 - 图1

1. 「引例」

有两个公司，房地产公司和服装制造公司。

「抽象公司」

public abstract class Corp {
  protected abstract void produce(); // 生产产品
  protected abstract void sell(); // 销售
  public void makeMoney() {
      // 先生产，再销售，从中获利
      this.produce();
      this.sell();
  }
}

「房地产公司实现」

public class HouseCorp extends Corp {
  // 盖房子
  protected void produce() {
      System.out.println("房地产公司盖房子...");
  }
  // 卖房子
  protected void sell() {
      System.out.println("房地产公司出售房子...");
  }
  // 计算利润
  public void makeMoney() {
      super.makeMoney();
      System.out.println("房地产公司赚大钱...");
  }
}

「服装公司实现」

public class ClothesCorp extends Corp {
  // 生产衣服了
  protected void produce() {
      System.out.println("服装公司生产衣服...");
  }
  // 卖服装
  protected void sell() {
      System.out.println("服装公司出售衣服...");
  }
  //赚钱
  public void makeMoney() {
      super.makeMoney();
      System.out.println("服装公司赚小钱...");
  }
}

「测试」

@Test
public void test() {
  System.out.println("-------房地产公司是这样运行的-------");
  HouseCorp houseCorp = new HouseCorp();
  houseCorp.makeMoney();
  System.out.println("-------服装公司是这样运行的-------");
  ClothesCorp clothesCorp = new ClothesCorp();
  clothesCorp.makeMoney();
}

———-房地产公司是这样运行的———- 房地产公司盖房子… 房地产公司出售房子… 房地产公司赚大钱… ———-服装公司是这样运行的———- 服装公司生产衣服… 服装公司出售衣服… 服装公司赚小钱…

服装厂转到小钱后，决定转型，于是开始生产山寨IPod，其他不变

public class IPodCorp extends Corp {
  protected void produce() {
      System.out.println("生产IPod...");
  }
  protected void sell() {
      System.out.println("IPod畅销...");
  }
  public void makeMoney() {
      super.makeMoney();
      System.out.println("IPod赚钱...");
  }
}

「测试」

@Test
public void test1() {
  System.out.println("-------房地产公司是按这样运行的-------");
  HouseCorp houseCorp = new HouseCorp();
  houseCorp.makeMoney();
  System.out.println("-------山寨公司是按这样运行的-------");
  IPodCorp iPodCorp = new IPodCorp();
  iPodCorp.makeMoney();
}

这样的小厂，随时都会根据市场的动向进行业务调整，而且是相对比较大的改变。所以不要把产品和工厂绑得太死。

具体的实现就省略了。
public abstract class Product
public class House extends Product
public class IPod extends Product
public abstract class Corp中添加一个有参构造，传入产品，子类都要重写父类的构造，以传入产品进行相应的业务。
这种情况下，假如房地产公司进行业务细化，将公司分为公寓房公司，别墅公司等等，对类图的也不会有太大的修改。
增加公司，要么继承Corp类，要么继承HouseCorp或ShanZhaiCorp，不用修改原有的类。
增加产品，继承Product类，或者继承House类，要把房子分为公寓房、别墅、商业用房等。
唯一要修改的就是Client类。类都增加了，高层模块也需要修改，也就是说Corp类和 Product类都可以自由地扩展，而不会对整个应用产生太大的变更，这就是桥梁模式。

2. 「定义」

Decouple an abstraction from its implementation so that the two can vary independently.

将抽象和实现解耦，使得两者可以独立地变化。

通用类图

Abstraction——抽象化角色
- 定义出该角色的行为，同时保存一个对实现化角色的引用，该角色一般是抽象类。
Implementor——实现化角色
- 它是接口或者抽象类，定义角色必需的行为和属性。
RefinedAbstraction——修正抽象化角色
- 它引用实现化角色对抽象化角色进行修正。
ConcreteImplementor——具体实现化角色
- 它实现接口或抽象类定义的方法和属性。

一句话就是：抽象角色引用实现角色，或者说抽象角色的部分实现是由实现角色完成的。

「实现化角色」

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

「具体实现化角色」

public class ConcreteImplementor1 implements Implementor {
  public void doSomething() {
      //业务逻辑处理
  }
  public void doAnything() {
      //业务逻辑处理
  }
}
public class ConcreteImplementor2 implements Implementor {
  public void doSomething() {
      // 业务逻辑处理
  }
  public void doAnything() {
      // 业务逻辑处理
  }
}

「抽象化角色」

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

添加一个有参构造，是为了让子类传入实现类，明确实现者。

「具体抽象化角色」

public class RefinedAbstraction extends Abstraction {
  //覆写构造函数
  public RefinedAbstraction(Implementor _imp) {
      super(_imp);
  }
  //修正父类的行为
  @Override
  public void request() {
      super.request();
      super.getImp().doAnything();
  }
}

「测试」

@Test
public void test() {
  Implementor imp = new ConcreteImplementor1(); //定义一个实现化角色
  Abstraction abs = new RefinedAbstraction(imp); // 定义一个抽象化角色
  abs.request(); // 执行行文
}

桥梁模式是一个非常简单的模式，它只是使用了类间的聚合关系、继承、覆写等常用功能，但是它却提供了一个非常清晰、稳定的架构。

3. 「优点」

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

4. 「使用场景」

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

5. 「注意事项」

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

6. 「最佳实践」

继承的优点有很多，可以把公共的方法或属性抽取，父类封装共性，子类实现特性，这是继承的基本功能。
缺点是强侵入，父类有一个方法，子类也必须有这个方法。这是不可选择的，会带来扩展性的问题。
- 我举个例子🌰来说明：Father类有一个方法A，Son继承了这个方法，然后GrandSon也继承了这个方法，问题是突然有一天Son要重写父类的这个方法，他敢做吗？绝对不敢！GrandSon要用从Father继承过来的方法A，如果修改了，那就要修改Son和GrandSon之间的关系，那这个风险就太大了！
- 桥梁模式描述了类间弱关联关系。Father类完全可以把可能会变化的方法放出去，Son子类要拥有这个方法很简单，桥梁搭过去，获得这个方法，GrandSon也一样，即使你Son子类不想使用这个方法也没关系，对GrandSon不产生影响，它不是从Son中继承来的方法！
对于比较明确不发生变化的，则通过继承来完成；若不能确定是否会发生变化的，那就认为是会发生变化，则通过桥梁模式来解决，这才是一个完美的世界。