桥梁模式亦是结构型设计模式的一种，从名字上理解，像是连接两个元素的一种模式，差不多可以这么理解，但桥梁模式并非是像适配器模式一样适配不适应的两个类的。

　　桥梁模式连接的抽象和实现，为了达到抽象和实现这两部分都能变化的目的，必须使用桥梁的聚合作用来达到。这里的抽象部分和实现部分不是我们通常认为的抽象父类和实现子类的关系，而是组合关系。实现部分是被抽象部分调用，以用来完成（实现）抽象部分的功能。

　　系统设计中，总是充满了变数，那么采取什么样的设计能较好的解决变化带给系统的影响？一般来说，设计原则是将不变的框架使用抽象类定义出来，然后再将容易变化的内容使用具体的子类来分别实现。这样面对客户使用，只是一个抽象类，当有需要的时候，通过添加新的实现子类来变化，由此缩小了变化带来的影响。但是这可能会造成子类数量的不断增多，并且在很多时候都不够灵活。

　　当实现子类上存在一些类似的行为，我们不妨将这些行为提取出来，也采用接口的方式开放调用，然后以组合的方式将服务提供给原来子类。

　　这就是桥梁模式的思想，我们来看看桥梁模式的一个例子类图来加深理解。

从这个例子中我们看出，不仅实现部分和抽象部分所提供的接口可以完全不一样；而且实现部分内部、抽象部分内部的接口也完全可以不一样。

桥梁模式有着自己适应的使用环境：

1、当你的系统有多个地方需要重用类似的行为、或是多个类似行为的组合时，桥梁模式能有效减少因为行为的差异产生的子类

2、系统中某个类的行为可能会有几种不同的变化趋势，为了有效的将变化封装，可以考虑将类的行为抽取出来

桥梁模式使用低耦合性的组合达到了不错的灵活性，是体现解耦性很好的设计模式。

设计模式之桥梁模式