设计模式学习笔记十三:外观模式(Facade Pattern)

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

     1.概述
     外观模式(Façade),为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层的接口,这个接口使得这个子系统更加容易使用。通过这个接口,其他系统可以方便的调用子系统中的功能,而忽略子系统内部发生的变化。
     外观模式(Façade)是经常使用的模式之一,并且可以应用在任何层次和粒度的应用中,小到API的封装,大到封装整个系统。例如在使用ADO.NET时,为了执行SQL,需要使用Connection,Command和DataAdapter等,这样显然比较的麻烦,因此我们可以将整个数据库访问封装到一个类中,该类封装了访问数据库的过程,这个类就是一个外观模式。
     下面我们看外观模式的结构:

 

     结构图说明:

     外观类(Facade):客户端可以调用这个类的方法。此类知晓相关的(一个或者多个)子系统的功能和责任。在正常情况下,本类会将所有从客户端发来的请求委派到相应的子系统去。

子系统(subsystem):可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类,而是一个类的集合。每一个子系统都可以被客户端直接调用,或者被外观类调用。子系统并不知道门面的存在,对于子系统而言,外观类仅仅是另外一个客户端而已。

     基本代码:(来自大话设计模式)

     四个子系统类:

Code

     外观类:

Facade

     客户端调用(由于Facade的作用,客户端可以根本不知道四个子系统类的存在):

Code

     2.实例

     数据库访问外观模式:

     在使用ADO.NET访问数据库时,我们通常需要编写下面的访问数据库的语句来访问数据库:

Code

     如上面的代码所示,为了执行一个SQL,需要使用Connection、Command和DataAdapter,这样显然比较麻烦,因此,我们可以利用外观模式,将数据库访问封装到一个类中,该类分装了访问数据库的过程。下面是给出一个通用的封装的数据访问层,代码如下:

 

DALResult

      SQL语句的分装:

SQL_Base

     存储过程的封装:

 

SP_Base

     3.总结

     何时采用外观模式:

     从代码角度来说, 如果你的程序有多个类是和一组其它接口发生关联的话可以考虑在其中加一个外观类型。
     从应用角度来说, 如果子系统的接口是非常细的,调用方也有大量的逻辑来和这些接口发生关系,那么就可以考虑使用Facade把客户端与子系统的直接耦合关系进行化解。你可能会说,子系统改了外观类不是照样改?的确是需要改,但是如果客户端本身的工作已经比较复杂,或者说可能有多个需要调用外观类的地方,这个时候外观类的好处就体现了。

 

     效果及实现要点

     1.Facade模式对客户屏蔽了子系统组件,因而减少了客户处理的对象的数目并使得子系统使用起来更加方便。

     2.Facade模式实现了子系统与客户之间的松耦合关系,而子系统内部的功能组件往往是紧耦合的。松耦合关系使得子系统的组件变化不会影响到它的客户。

     3.如果应用需要,它并不限制它们使用子系统类。因此你可以在系统易用性与通用性之间选择。

     4.通过一个高层接口让子系统和客户端不发生直接关联,使客户端不受子系统变化的影响。

     5.Facade不仅仅针对代码级别,在构架上,特别是WEB应用程序的构架上,Facade的应用非常普遍。如常常说的三层架构就是典型的外观模式。

 

     参考资料:

     大话设计模式

     http://terrylee.cnblogs.com/archive/2006/03/17/352349.html

     http://www.cnblogs.com/lovecherry/archive/2007/10/07/916202.html


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