八、 Bridge 桥接（结构型模式）

1. 动机
思考上述问题的症结：事实上由于Tank类型的固有逻辑，使得Tank类型具有了两个变化的维度——
一个变化的维度为“平台的变化”，一个变化的维度为“型号的变化”。
如何应对这种“多维度的变化”？如何利用面向对象技术来使得Tank类型可以轻松地沿着“平台”和“型号”两个方向变化，而不引入额外的复杂度？

2. 意图
将抽象部分与实现部分分离，使它们都可以独立地变化。

3. 结构

4. 几个要点
•Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有 的绑定关系，使得抽象（Tank的型号）和实现（不同的平台）可以沿着各自的维度来变化。
• 所谓抽象和实现沿着各自纬度的变化，即“子类化”它们，比如 不同的Tank型号子类，和不同的平台子类）。
得到各个子类之后，便可以任意组合它们，从而获得不同平台上的不同型号。
•Bridge模式有时候类似于多继承方案，但是多继承方案往往违背单一职责原则（即一个类只有一个变化的原因），复用性比 较差。
Bridge模式是比多继承方案更好的解决方法。
•Bridge模式的应用一般在“两个非常强的变化维度”，有时候即使 有两个变化的维度，
但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果，并不一定要使用 Bridge模式。

5. 个人体会
    桥接模式就是使用“对象组合” 的方式，将某一个维度的变化分离到主对象的外面，从而隔离变化。
    是否可以用于应对多维度变化--两个以上的维度？