设计模式学习笔记十二:桥接模式(Bridge Pattern)

长平狐 发布于 2013/06/17 12:55
阅读 67
收藏 0

    1.概述
    桥接模式(Bridge),将抽象部分与它的实现部分分离,是他们都可以独立的变化。
什么叫抽象与它的实现分离,这并不是说,让抽象类与其他派生类分离,因为这没有任何意义。实现指的是抽象类和它的派生类用来实现自己的对象。
    下面我们看桥接模式的结构图:

    (1).Abstraction:定义抽象类的接口并维护指向Implementor类的对象指针。
    (2).RefinedAbstraction:扩充Abstraction定义的接口。
    (3).Implementor:定义实现类的接口,该接口不一定要与Abstraction的接口完全一致。事实上这两个接口可以完全不同。一般而言,Implementor接口仅提供基本操作,而Abstraction则定义基于这些基本操作的较高层次的操作。
    (4).ConcreteImplementor:实现Implementor接口并定义它的具体实现。
    桥接模式基本代码如下:
    Implementor类:
Implementor
ConcreteImplementor等派生类:
ConcreteImplementorA
    Abstraction类:
Abstraction
    RefinedAbstraction类:
RefinedAbstraction

    2.实例
    为了跟深入的了解桥接模式(Bridge),我们来看大话设计模式中手机软件的演变过程。 先来看看小菜的第一版代码,结构如下:

    详细代码如下:

HandsetBrand
    调用:
调用
    下面来小菜的第二方案,结构图如下:

    代码如下:
HandsetSoft
    下面大鸟登台,给出的桥接模式的解决方案,先来结构图:

    代码如下:
Bridge

    3.总结
    效果及实现要点:
    1.Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系,使得抽象和实现可以沿着各自的维度来变化。
    
2.所谓抽象和实现沿着各自维度的变化,即“子类化”它们,得到各个子类之后,便可以任意它们,从而获得不同平台上的不同型号。
    3.Bridge模式有时候类似于多继承方案,但是多继承方案往往违背了类的单一职责原则(即一个类只有一个变化的原因),复用性比较差。Bridge模式是比多继承方案更好的解决方法。
    4.Bridge模式的应用一般在“两个非常强的变化维度”,有时候即使有两个变化的维度,但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果,并不一定要使用Bridge模式。
    何时采用
    在以下的情况下应当使用桥梁模式:
    1.如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性,避免在两个层次之间建立静态的联系。 
    
2.设计要求实现化角色的任何改变不应当影响客户端,或者说实现化角色的改变对客户端是完全透明的。 
    
3.一个构件有多于一个的抽象化角色和实现化角色,系统需要它们之间进行动态耦合。 
    
4.虽然在系统中使用继承是没有问题的,但是由于抽象化角色和具体化角色需要独立变化,设计要求需要独立管理这两者。
    
    参考资料:
    1.大话设计模式
    2.http://terrylee.cnblogs.com/archive/2006/02/24/336652.html

 


原文链接:http://www.cnblogs.com/peida/archive/2008/07/17/1244690.html
加载中
返回顶部
顶部