008.设计模式之Bridge模式

008.设计模式之Bridge模式

 

Window下一个绘图系统, 可以绘制圆形, 正方形. 因为正方形与圆形都需要绘制, 所以我定义如下:

 

但现在要支持Linux

看下面设计:

烂设计1

 

 

本来画图系统中就不会分什么Linux形状和Window形状, 也没有分Linux圆形和Window圆形, 从分类的角度, 这样子分就不对了. 如果以后增加了苹果系统的呢?

 

烂设计2

 

同烂设计1

如果有100种形状, 增加一种操作系统, 那也要增加100个类

 

使用桥模式

 

将抽象和行为划分开来,各自独立,但能动态的结合。

如果增加自用系统, 在右边增加一个系统类就可以了, 使用者就用该系统的对象组合一下.

任何事物对象都有抽象和行为之分，例如人，人是一种抽象，人分男人和女人等；人有行为，行为也有各种具体表现，所以，“人”与“人的行为”两个概念也反映了抽象和行为之分。

在面向对象设计的基本概念中，对象这个概念实际是由属性和行为两个部分组成的，属性我们可以认为是一种静止的，是一种抽象，一般情况下，行为是包含在一个对象中，但是，在有的情况下，我们需要将这些行为也进行归类，形成一个总的行为接口，这就是桥模式的用处。

为什么使用?
不希望抽象部分和行为有一种固定的绑定关系，而是应该可以动态联系的。

如果一个抽象类或接口有多个具体实现(子类、concrete subclass),这些子类之间关系可能有以下两种情况:
1. 这多个子类之间概念是并列的,如前面举例,打桩,有两个concrete class:方形桩和圆形桩;这两个形状上的桩是并列的,没有概念上的重复。

2.这多个子类之中有内容概念上重叠.那么需要我们把抽象共同部分和行为共同部分各自独立开来,原来是准备放在一个接口里,现在需要设计两个接口：抽象接口和行为接口，分别放置抽象和行为.

例如,一杯咖啡为例,子类实现类为四个：中杯加奶、大杯加奶、中杯不加奶、大杯不加奶。

但是，我们注意到：上面四个子类中有概念重叠，可从另外一个角度进行考虑，这四个类实际是两个角色的组合：抽象和行为，其中抽象为：中杯和大杯；行为为：加奶 不加奶（如加橙汁 加苹果汁）.

实现四个子类在抽象和行为之间发生了固定的绑定关系，如果以后动态增加加葡萄汁的行为，就必须再增加两个类：中杯加葡萄汁和大杯加葡萄汁。显然混乱,扩展性极差。

那我们从分离抽象和行为的角度，使用Bridge模式来实现。

设计过程中, 要注意抽象与行为的提取正确性. 在一些分类, 组合的设计问题上, 我们实现时应该选择组合而不是继承.

 

代码

     CRotundity    *pRotundity   = new CRotundity;

     CSquare       *pSquare = new CSquare;    

     CLinux        *pLinux       = new CLinux;

     CWindows *pWindow = new CWindows;

 

     pRotundity->SetSystem(pLinux);

     pRotundity->Draw();

 

     pRotundity->SetSystem(pWindow);

     pRotundity->Draw();

 

     pSquare->SetSystem(pLinux);

     pSquare->Draw();

 

     pSquare->SetSystem(pWindow);

     pSquare->Draw();

 

     delete pRotundity;

     delete pSquare;   

     delete pLinux;        

     delete pWindow;   

     return 0;

 

看代码008Bridge.rar

 

总结

其实Bridge模式和类似于分类/组合, 就是一类事物按照不同的规格分类, 各个分类组合起来, 就组成了不同特征的给类事物的一个实例.

Bridge模式中就是按抽象与行为来分, 提取事物有哪些抽象, 有哪些行为, 提取出来后, 不同的抽象, 行为组成成不同特征的事物.

引用

http://www.jdon.com/designpatterns/bridge.htm