设计模式面面观（10）：桥接模式（Bridge Pattern）-结构型模式

桥接模式（Bridge）-结构型模式

 

    桥接模式是将抽象化与实现进行脱藕的一种模式，使一个类实例化和他的行为解耦合，让他们可以有自己独立的变化空间，而不会因为类行为过多依赖类本身或类本身被类行为牵制，带来的变化受制的问题。这里需要主意的是桥接模式是将类和类行为现实减弱耦合关联并不一定要完全解耦合，当然如果可以的话完全解耦合的设计方案更优。

    在设计时的运用请看下面的UML图

在生活中我们有各种各样的交通工具供我们使用，如果需要我们设计出这个交通工具和他们的基本使用，我们知道交通工具基本上分海陆空三种，每种工具的操作流程差异非常大，就是同类型的交通工具在操作上也有细微的差别，如果我们只抽象出一个交通工具的抽象类，我们需要依据交通工具的类型判断他们的基础操作，噢！天哪世界上那么多的交通工具要写多少的条件判断，以后如果我要想加一种类型的交通工具就要更改原有设计，所以这是一种糟糕的设计！由于交通工具的实现和实体类的行为都在不停的变化，所以我们要尽量的把变化的地方封装起来。这样就引用到我们现在学习的桥接模式了，解耦合，类实现与类行为是桥接模式的拿手绝活。

我们来看看一个优化后的设计

       首先：    我们抽象出类的实现接口和行为接口（IVehick，IRunHandle）

       其次：    抽现出海陆空三种抽象的交通工具类和3中交通工具的基本操作类，并且抽象类实现部分包含抽现类行为，让抽象类依赖与抽现类行为。

       最后：    现在我们想要的3中交通工具类和他们的行为

让我们回头看看这个OOD设计是否合理，我们依据我们第二章的设计模式原则来判定

1.    是否符合开闭原则

我们在新增一种交通工具的时候只需要实现他们的类和行为即可。

答案：符合

2.    是否符合里氏代换原则

不用多说了。

答案：符合

3.    是否符合依赖倒置原则

交通工具类依赖与交通工具操作抽象类

答案：符合

4.    是否符合接口隔离原则

IVehick，IRunHandle 一个接口负责管理实现一个类，一个接口负责管理类行为

如果原始设计的话IVehick接口可以包含IRunHandle接口这样就紧耦合了

答案：符合

5.    是否符合抽象原则

答案：符合

6.    是否符合迪米特法则

答案：符合

 

 

总结 ：桥接模式

意图：

将抽现部分与他们的实现分离，使他们能够独立的变化

动机：

当一个抽象可能有多个实现（交通工具有海陆空3中实现）通常我们用继承类协调他们，抽象类定义对该抽象的接口而集体的子类则用不同方式加以实现。但此方法有时不够灵活。继承机制将抽象部分与实现部分固定在一起，使得难以对抽象部分和实现部分独立地进行修改、扩充和重用。

适用性：

l         不希望在抽象和它的实现部分之间有一个固定的绑定关系

l         类的抽象以及它的实现都应该可以通过生成子类的方法加以扩充。

l         对一个抽象的实现部分的修改应该对客户不产生影响

结构：

 

参与者：

l         Abstraction                          （Car, ship,airpalin）                                

l         RefinedAbstraction               (XianDai,BoYin747,HaiShenYouLun)

l         Implementor                       (IRunHandle)

l         ConcreteImplementor           (CarHandle,ShipHandle,AirplainHandle)     

Bridge模式的优点：

1.         分离接口以及实现部分

2.         提高可扩充性

3.         现在细节对用户透明（可隐藏实现细节）

代码：

 

 http://download.csdn.net/source/327748