设计模式（6）--Bridge 桥接模式

这个模式在实际开发中应该是使用非常多的，不知不觉中我们就使用了桥接模式。我们拿电脑举例（Apple）除外。如果让你动手攒一个台式机，你可以上京东，在电脑产品体系里选择各种配件，组装出一台电脑。那么这个各种配件和电脑之间，是什么关系呢？显然是has-a而不是is-a的关系。这个道理即是如果能使用合成则优先考虑合成而非继承，除非确实是is-a的关系。

假如你用继承is-a的关系来表示整个电脑的产品体系，那么将会非常的繁琐，你需要不断的创建父类和具体的子类来完成产品的搭建。比如：外星人->大机箱->USB3.0接口1，Razer->中机箱->USB3.0接口1。会有很多不计其数具体的子类。 显然，实际当中的电脑产品体系并不是这么划分的。只要有同一的生产标准，我们就应该把各类配件分离而出，自己独立的抽象和继承。并通过has-a（或聚合）的关系与电脑关联（桥接）起来。这样，不论有几个品牌的台式机，我们都只会有一个机箱抽象类和大中小三个具体机箱类。这就是桥接模式。

在桥接模式中还提到了一种“聚合”形式，即has-a的弱版本，两者之间的相互关联并不是严格必须的。例如机箱和台式机是合成关系，机箱和水冷系统则是聚合关系。

桥接模式在实际开发中的例子太多了，这种设计思维也是程序员日常中经常使用到的，所以不展开代码，再举一个实例：
一个系统中按时间先后相继开发上线了三个贷款产品。每个贷款产品都需要查询征信报告并且分析征信报告，但查询和分析的具体规则不同。由于在开发第一个产品的时候，未做甚远考虑，征信查询功能只有自己具体的实现类。
在第二个产品开发时，很自然的，我们不会去开发产品2->征信查询类。我们肯定是对征信查询类做抽象，然后，写出符合产品2规则的具体实现，然后以合成的方式提供给产品2使用。这样即使将来产品1的规则变成和产品2一样，那我们也没必要再去修改任何代码，直接将现在符合产品2规则的实现提供给产品1使用即可。这样，产品维度自己变化，征信查询维度自己变化，并不会因为紧耦合的关系而带来很大的代码变化工作。