Bridge模式

1.问题：一个抽象类的不同派生类使用不同的实现，此时容易出现类数量爆炸性增长。

2.解决：为实现封装为另一个抽象类B，供抽象类A的所有派生类使用。将实现与使用它们的对象分离。

3.定义：桥接模式就是将抽象与其实现解耦，使它们可以独立的变化。（这里的实现是指抽象类及其派生类中用来实现自己逻辑的其它对象，而抽象类的派生类被称为具体类）。

              抽象是指事物之间在概念上的联系。

              解耦是指让事物互相独立的行事。

4.补充：它遵循设计模式社区的两大原则：找出变化并封装之；优先使用对象聚集，而不是类继承。

              当抽象的派生类的种类与抽象内部实现的逻辑对象出现组合爆炸的情况时，就需要有一种方式将抽象上的变化与实现上的变化分开，使类的数量变为线性增加。

              当抽象的逻辑实现多变时，可能会出现类爆炸性增长的问题。例如不同形状类，需要再根据使用不同的绘图程序实例出更多形状类。需要把这个增长变为线性的。

              一条规则实现一次，有助于重构。

             重构：不改变代码的外在行为，而是改进它的内部结构。但一般不增加功能的改变 进都可以称为重构。

              对象聚集与继承最大的区别在于，方法放在了不同的类中。

              Bridge模式将实现看成对象之外的东西，对象所使用的东西，这样使变化隐藏在实现中，与调用程序隔离开了。

              衡量设计质量的一种方法是看它是否很好的应对变化。

              常使用抽象，为很多未知的实例做准备，但这会使类的数量增加。

              要学会用对象的职责，而不是其结构来思考问题。

             继承到组合的转变，就是“为每种特化使用不同的变化”到“将变化转移到使用或拥有这种变化的对象中”的转变

             很多开发人员喜欢对最开始提出的设计方案从一而终，勇于寻找原设计的替代方案，考虑怎么克服原设计中的缺陷的做法是非常提倡，鼓励，推荐的。

             将所有的变化都分别放在自己的抽象类中，然后观察这些抽象类之间的关系。

             一条规则，一个地方。我不是纯粹主义者，如果有什么地方让我认为总要遵循原则的，这就是。它有助于重构。

             重构refactoring：是一种修改软件系统的过程，改进代码的内部结构，而不增加功能，不改变代码的外在行为。

             Bridge模式常与Adapter模式结合使用，这就是复合设计模式。

             模式并不总能提供十全十美的解决方案，但它通常优于我们在有限时间内能提出的解决方案。它将可能出现的变化修改影响控制在了局部，降低了出现副作用的风险。

5.对象的继承关系在编译时就定义好了，无法在运行时改变。子类的实现与父类有紧密的依赖关系。这种依赖关系限制了复用的灵活性。

   有了新锤子，所有的东西看上去都成了钉子。—对继承的滥用心理。

6.合成/聚合复用原则

    聚合 Aggregation表示弱拥有关系；

    组合 Composition表示强拥有关系，体现了严格的部分和整体的关系，它们的生命周期一样。

    优先使用对象的组合聚合，有助于保持每个类被封装，并被集中在单个任务上，类和类继承层次保持小规模。

            

7.实现系统可能有多种角度分类，每一种分类都有可能变化。那么就把这多种角度分离出来，让它们独立变化，减少耦合。

   很多设计模式就是原则的应用，理解原则是基础。