设计模式学习笔记十四:适配器模式、桥接模式与外观模式

长平狐 发布于 2013/06/17 12:54
阅读 130
收藏 1

     1.适配器模式与桥接模式的区别和联系

     适配器模式和桥接模式都是间接引用对象,因此可以使系统更灵活,在实现上都涉及从自身以外的一个接口向被引用的对象发出请求。

     两种模式的区别在于使用场合的不同,适配器模式主要解决两个已经有接口间的匹配问题,这种情况下被适配的接口的实现往往是一个黑匣子。我们不想,也不能修改这个接口及其实现。同时也不可能控制其演化,只要相关的对象能与系统定义的接口协同工作即可。适配器模式经常被用在与第三方产品的功能集成上,采用该模式适应新类型的增加的方式是开发针对这个类型的适配器,如下图所示:

     桥接模式则不同,参与桥接的接口是稳定的,用户可以扩展和修改桥接中的类,但是不能改变接口。桥接模式通过接口继承实现或者类继承实现功能扩展。如下图所示:
 
      按照GOF的说法,桥接模式和适配器模式用于设计的不同阶段,桥接模式用于设计的前期,即在设计类时将类规划为逻辑和实现两个大类,是他们可以分别精心演化;而适配器模式用于设计完成之后,当发现设计完成的类无法协同工作时,可以采用适配器模式。然而很多情况下在设计初期就要考虑适配器模式的使用,如涉及到大量第三方应用接口的情况。
      2.适配器模式与桥接模式的联合
     在实际应用中,桥接模式经常和适配器模式同时出现,如下图所示:
 
 
     
     这种情况经常出现在需要其他系统提供实现方法时,一个典型的例子是工业控制中的数据采集。不同工控厂家提供的底层数据采集接口通常不同,因此在做上层软件设计无法预知可能遇到何种接口。为此需要定义一个通用的采集接口,然后针对具体的数据采集系统开发相应的适配器。数据存储需要调用数据采集接口获得的数据,而数据可以保存到关系数据库、实时数据库或者文件中,。数据存储接口和数据采集结构成了桥接,如下图所示:
 
    
 同样的结构也经常出现在报表相关的应用中,报表本身结构和报表输出方式完全可以分开,如下图所示:
 
     
     如上图所示,报表输出可以单独抽象出来与报表的具体形式分开。但报表输出又依赖于具体的输出方式,如果需要输出为PDF格式,则需要调用与PDF相关的API,而这是设计所无法控制的,因此这里需要适配器模式。
      3.适配器模式与外观模式的关系
     适配器模式与外观模式有些相似,都是对现存系统的分装。但这两种模式的意图完全不同,前者使现存系统与正在设计的系统协同工作,而后者则为显存系统提供一个更为方便的访问接口。简单的说,适配器模式为事后设计,而外观模式则必须事前设计,因为系统依赖于外观。总之,适配器模式没有引入新的接口,而外观模式则定义了一个全新的接口。
     适配器模式用于粒度较小的功能集成,如使用权威部门所固定的无法修改并替换的现有算法模块,将来也可能升级,这时可以使用适配器模式。
     外观模式的使用有时比较难把握,外观接口的定义与设计人员对业务的理解程度有很大的关系。如果接口设计过于复杂,则不如直接调用原系统简单;如果接口设计过于简单,有些功能需要调用原有系统才能实现,同样达不到分装的目的。在这种情况下,首先要考虑被封装系统的稳定程度。如果系统处于演化阶段,那么接口定义需要复杂一些,以暴露更多的接口。这时,外观模式更像一个大粒度的适配器。被封装的系统发生演化时,需要新的外观对象,而这个外观对象起到了适配器的作用,如下图所示位这种情况下的结构:
      
      总结
     适配器模式经常用在需要第三方API协同工作的场合,在功能集成需求越来越多的今天,这种模式的使用频度越来越高,特别是桥接模式与适配器模式的组合在设计中越来越频繁的出现,几乎成为一种新的设计模式。
     外观模式是另一个在系统演化中常用的模式,在某些情况下,它与适配器模式的作用有些相似,但总体上来说,外观模式所针对的对象粒度更大。
 
     参考资料:
     .NET与设计模式 

原文链接:http://www.cnblogs.com/peida/archive/2008/08/01/1257574.html
加载中
返回顶部
顶部