问题描述

现在要去画一个图形，图形有长方形、圆形和扇形等等；而图形又可以加上不同的颜色，然后，我们就可以画出红色的长方形，绿色的长方形；红色的圆形，绿色的圆形等等。而这种图形的形状在变化，图形的颜色也在变化，当使用代码去实现时，如何面对这种多方面的变化呢？这就要说到今天的桥接模式了。

什么是桥接模式？

对于上述的图形与颜色的问题时，很多时候，我们让各个图形类继承颜色类，比如：

每当我们增加一个新的图形，或者增加一种新的颜色时，对应的类就会以相乘的速度进行增加。当系统中的类变的多时，对应的管理也就变的复杂，这不是我们希望看到的。同时，我们可以看到CRedRectangle类继承自CRed类，这种继承关系合理吗？且不说有的系统是如此实现的，红色的矩形是红色吗？很显然，CRedRectangle和CRed之间不是一种is-a的关系，所以，上面的实现是及其不合理的。那么它们是什么关系呢？接着往下看。

在GOF的《设计模式:可复用面向对象软件的基础》一书中对桥接模式是这样说的：将抽象部分和它的实现部分分离，使它们都可以独立的变化。简单粗暴的说，就是抽象对外提供调用的接口；对外隐瞒实现部分，在抽象中引用实现部分，从而实现抽象对实现部分的调用，而抽象中引用的实现部分可以在今后的开发过程中，切换成别的实现部分。

为什么要使用桥接模式？

当一个抽象可能有多个实现时，通常用继承来协调它们。抽象类定义对该抽象的接口，而具体的子类则用不同方式加以实现。但是此方法有时不够灵活。继承机制将抽象部分与它的实现部分固定在一起，使得难以对抽象部分和实现部分独立的进行修改、扩充和重用。桥接模式把依赖具体实现，提升为依赖抽象，来完成对象和变化因素之间的低耦合，提高系统的可维护性和扩展性。桥接模式的主要目的是将一个对象的变化与其它变化隔离开，让彼此之间的耦合度最低。

什么时候使用桥接模式？

1.如果不希望在抽象和它的实现部分之间有一个固定的绑定关系，也就是继承关系；如果我们打破了这种固定的绑定关系，以后，就可以方便的在抽象部分切换不同的实现部分；

2.如果希望类的抽象以及它的实现都应该可以通过生成子类的方法加以扩充；如果不使用桥接模式，使用继承去实现时，在抽象类中添加一个方法，则在对应的实现类中也需要做对应的改动，这种实现不符合松耦合的要求；

3.如果要求对一个抽象的实现部分的修改对客户不产生影响，即客户的代码不需要重新编译，在后面的项目经验会说这方面；

4.如果想对客户完全隐藏抽象的实现部分；

5.如果一个对象有多个变化因素的时候，通过抽象这些变化因素，将依赖具体实现，修改为依赖抽象；

6.如果某个变化因素在多个对象中共享时，可以抽象出这个变化因素，然后实现这些不同的变化因素。

上面使用的场景，是一种建议，也是一种参考。在项目中要很好的把握一个设计模式，是有一定的难度的；当在实际项目中遇到满足上面的一点或者几点时，可以考虑使用桥接模式。

UML类图

Abstraction类定义了抽象类的接口，并且维护一个指向Implementor实现类的指针；

RefineAbstraction类扩充了Abstraction类的接口；

Implementor类定义了实现类的接口，这个接口不一定要与Abstraction的接口完全一致；实际上，这两个接口可以完全不同；

ConcreteImplementor类实现了Implementor定义的接口。

代码实现