桥接模式 -- Bridge

2017-03-26 19:05:16   最后更新: 2017-03-26 19:05:16   访问数量:453




桥接模式是将抽象部分与实现部分分离,来让他们可以独立的变化

面向对象的继承机制很好的解决了在一个维度上的抽象,但是对于多维度的抽象就会显得难以实现

比如我们有一个用于图形界面开发的抽象类 Window,此时,我们需要为 osx 平台和 windows 平台开发 Window 的实现类 XWindow 类和 WWindow 类,而如果我们需要实现一个继承自 Window 类的 IconWindow 类,那么我们还需要分别实现 OSX 的 XIconWindow 类和 WIconWindow 类,随着我们不断地增加组件,我们的类最终会呈现爆炸性的增长趋势

Bridge 模式将抽象的 Window 与他的具体实现分别放在独立的类层次结构中,从而解决了这个问题

 

如上图所示,Window 类应该仅仅描述接口而不涉及具体的实现,而具体的实现应该是独立于 Window 类单独存在的

使用桥接模式可以很方便的处理这种多维度抽象的问题,降低类与类之间的耦合,轻松实现在多个方向上进行变化,又不会引入额外的复杂度

 

  • 不希望类的抽象和他的实现之间有一个固定的绑定关系,例如程序的运行时刻才选择或切换不同的实现
  • 需要对不同维度加以组合和扩充来生成子类
  • 对一个抽象的实现部分的修改对客户不产生影响
  • 在层次结构中,一个对象必须被分解成两部分来生成

 

 

 

如上图所示,Bridge 由下列组件构成:

  1. Abstraction -- 定义抽象类的接口,维护一个指向其实现类型对象的指针,对应第一幅图中的 Window 或 Platform
  2. RefinedAbstraction -- 扩充由 Abstraction 定义的抽象接口,对应第一幅图中的 Icon、File、OSX 等
  3. Implementor -- 定义实现类的接口,该接口不一定与 Abstraction 的接口完全一致,Abstraction 定义了一套较高层次的操作,而 Implemention 定义的则是底层的基本操作,他们并没有对应关系
  4. ConcreteImplementor -- 实现 Implementor 接口并定义他的具体实现

 

Abstraction 的工作是将 client 的请求转发给他的 Implementor 对象,也就是说用户实际操作的是 RefinedAbstraction 这一层的类对象

独立的接口抽象与实现抽象完全分离了接口与实现这两层,而 RefinedAbstraction 可以在运行时动态绑定到具体的 ConcreteImplementor 来改变他的实现,并且我们可以随时为我们的系统添加不同的实现,而对客户则是完全透明的

关于 Abstraction 与 Implementor,结合我们之前的例子,用户需要调用某种 window 的 open() 操作,但是实际上,在 RefinedAbstraction 中,对于 Icon 来说,open() 操作是通过传入坐标及文件路径调用 Implementor 的 draw() 方法完成的,这个例子就可以看出 Abstraction 与 Implementor 并无一一对应的关系,实际中情况可能更加复杂一些

 






读书笔记      技术帖      龙潭书斋      设计模式      design pattern      bridge      桥接模式      桥连模式      结构型模式     


京ICP备15018585号