设计模式之Bridge模式

本文内容是通过学习《设计模式解析》 by - Alan Shalloway, James R. Trott 一书所总结的心得。

博主想通过先提出问题，再解决问题的方式来让读者实际体验一把Bridge模式的优势。（这也是《设计模式解析》一书中采用的讲解流程，对于读者理解会有很大帮助）文中的案例也是使用的书中提供的案例。

1.提出问题

先看需求：有两个绘制实例D1和D2，它们都提供了drawLine和drawCircle方法，但是方法的内部实现逻辑是不一样的。需要分别使用它们来绘制Rectangle和Circle两种形状。请问要如何实现？

各位看官不如自己思考一下自己将如何实现这个需求。。。

首先，我们创建一个Shape类，创建D1Shape和D2Shape并且它们都继承于Shape，它们分别对应于D1和D2两个绘制实例。
其次，为了解耦我们让Rectangle和Circle类负责自己的绘制，比如Rectangle的绘制就在draw()方法中完成，实现过程就是调用D1的drawLine方法四次即可。
最后，因为有两种绘制实例D1和D2，那么就需要分别与之对应的D1Rectangle，D2Rectangle，D1Circle，D2Circle，它们四个分别继承于D1Shape和D2Shape类。
那么类图如下所示：

OK，需求已经实现了。
但是问题也很明显，如果此时要增加一种形状Oval，那么就需要新增两个类D1Oval,D2Oval，这是一种爆炸式增长。而若是增加一种绘制实例D3，那简直变成一个鬼畜般的需求了。。。
所以，上面的这种设计方式肯定是不行的，那么到底要怎样来设计呢？

2.解决问题

既然要写的是Bridge模式，那么肯定是用桥接模式来解决这个问题。
首先，我们来抽象一下这个具体的问题，以便我们在其他地方遇到类似问题也能想到Bridge模式
这里包含一个抽象概念Shape和一个实现概念绘制实例D1,D2,而在我们上面的方案中Shape和D1，D2是紧耦合的，所以当需求变更时，需要大量的修改。
而Bridge模式的目的就是：将抽象与实现进行解耦。这里的“实现”是上文提到的“实现概念”，而不是说某个接口的实现类。这里比较不好理解。
那么，Bridge模式如何实现解耦呢？
首先，我们还是创建Shape类，但是不创建D1Shape和D2Shape。
其次，我们将D1和D2抽象出一个Drawing接口，然后让Drawing1和Drawing2分别实现这个接口，并且使Drawing1对应D1,Drawing2对应D2（这里可通过Adapter模式将D1,D2包装进去）
接着，我们在Shape中添加一个Drawing对象，在绘制的时候通过Drawing对象来执行绘制。
请看类图：

我们只要在创建Shape时通过构造函数将Drawing对象传递进来就可以了。

public void Shape(Drawing drawing){
    this.drawing = drawing;
}

这样整个Bridge模式就实现了，顺带还实现了一把Adapter模式，这两种模式关系比较密切，但并不是说这两种模式一定会一起出现！！！
说了这么多，那这么设计到底有什么优点呢？
1.请您自己去检查下需求是否实现了。。。
2.如果需要新增一个D3，我们只需要新建一个Drawing3即可
3.如果要增加一种shape，如果这种shape也是通过drawLine和drawCircle方法来绘制，那从Shape类派生一个子类即可。
4.如果3中的条件不满足，就会稍微麻烦一点。比如增加椭圆Oval，需要一个drawOval方法来绘制。这时就需要修改Drawing接口。但是这种麻烦也在可接受范围内吧！

到此，Bridge模式就讲完了，主要是个人的一些心得，大家当作一个参考就好。