《设计模式》-桥梁模式

　　桥梁模式的用意是“将抽象化(Abstraction)与实现化(Implementation)脱耦，使得二者可以独立地变化”

　　所谓耦合，就是两个实体的行为的某种强关联。而将它们的强关联去掉，就是耦合的解脱，或称脱耦。在这里，脱耦是指将抽象化和实现化之间的耦合解脱开，或者说是将它们之间的强关联改换成弱关联。

　　将两个角色之间的继承关系改为聚合关系，就是将它们之间的强关联改换成为弱关联。因此，桥梁模式中的所谓脱耦，就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以相对独立地变化。这就是桥梁模式的 。

　　结构图：

　　

　　这个图中包含了2个结构：、

　　1）由抽象化角色和修正抽象化角色组成的抽象化等级结构。

　　2）由实现化角色和两个具体实现化角色所组成的实现化等级结构。

　　抽象化(Abstraction)角色：抽象化给出的定义，并保存一个对实现化对象的引用。 

　　修正抽象化(Refined Abstraction)角色：扩展抽象化角色，改变和修正父类对抽象化的定义。

　　实现化(Implementor)角色：这个角色给出实现化角色的接口，但不给出具体的实现。必须指出的是，这个接口不一定和抽象化角色的接口定义相同，实际上，这两个接口可以非常不一样。实现化角色应当只给出底层操作，而抽象化角色应当只给出基于底层操作的更高一层的操作。

　　具体实现化(Concrete Implementor)角色：这个角色给出实现化角色接口的具体实现。

　　在以下情况下应当 使用桥梁模式：

　　　　1）如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系。

　　　　2）设计要求实现化角色的任何改变不应当影响客户端，或者说实现化角色的改变对客户端是完全透明的。

　　　　3）一个构件有多于一个的抽象化角色和实现化角色，系统需要它们之间进行动态耦合。

　　　　4）虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。

　　总结：开篇就说到 理解好这个桥梁模式 对理解面向对象的 二大原则 很有帮助“开闭原则”、“组合聚合原则”。可以看到整个结构 是有一个类 里面 聚合一个抽象结构，并且自己还拥有一个可以被重写的虚方法，那么在使用的时候 可以通过重写自己的虚方法调整自己的功能，然而在功能扩展的时候可以通过继承 抽象类进行扩展。 那么客户端就可以不用改变自己的使用方式。里面的组合聚合原则就是类里面聚合了抽象类，而开闭原则 就是可以基于抽象类进行无限扩展，以及针对自己也可以进行各种需要的重写逻辑。