门面模式

引子

门面模式是非常简单的设计模式。

门面模式(facade)又称外观模式。GOF在《设计模式》一书中给出如下定义:为子系统中的一组接口提供一个一致的界面, Facade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。

定义中提到的子系统是指在设计中为了降低复杂性根据一定的规则(比如业务、功能),对系统进行的划分。子系统中封装有一些类。客户程序在使用子系统的时候,可能会像下图一样零乱。

在这里插入图片描述

在上面的实现方法中,客户类紧紧地依赖在子系统的实现上。子系统发生的变化,很可能要影响到客户类的调用。而且子系统在不断优化、可重用化的重构路上,会产生更多更小的类。这对使用子系统的客户类来说要完成一个工作流程,似乎要记住的接口太多了。

门面模式就是为了解决这种问题而产生的。看看使用了门面模式后的图:

在这里插入图片描述

这样就减少了客户程序和子系统之间的耦合,增加了可维护性。

很明显,门面模式有三个角色组成:

门面角色(facade):这是门面模式的核心。它被客户角色调用,因此它熟悉子系统的功能。它内部根据客户角色已有的需求预定了几种功能组合。

子系统角色:实现了子系统的功能。对它而言, facade角色就和客户角色一样是未知的,它没有任何facade角色的信息和链接。

客户角色:调用facade角色来完成要得到的功能。

Facade 模式的一个典型应用就是进行数据库连接。一般我们在每一次对数据库进行访问,都要进行以下操作:先得到 connect 实例,然后打开 connect 获得连接,得到一个statement,执行 sql 语句进行查询,得到查询结果集。

我们可以将这些步骤提取出来,封装在一个类里面。这样,每次执行数据库访问只需要将必要的参数传递到这个类中就可以了。

有兴趣可以在你正在进行的系统中实现一下。

《设计模式》给出了门面模式的使用环境:

当你要为一个复杂子系统提供一个简单接口时。在上面已经描述了原因。
客户程序与抽象类的实现部分之间存在着很大的依赖性。引入 facade 将这个子系统与客户以及其他的子系统分离,可以提高子系统的独立性和可移植性(上面也提到了)。
当你需要构建一个层次结构的子系统时,使用 facade 模式定义子系统中每层的入口点。如果子系统之间是相互依赖的,你可以让它们仅通过 facade 进行通讯,从而简化了它们之间的依赖关系。

以下是它的优点:

它对客户屏蔽子系统组件,因而减少了客户处理的对象的数目并使得子系统使用起来更加方便。
它实现了子系统与客户之间的松耦合关系,而子系统内部的功能组件往往是紧耦合的。松耦合关系使得子系统的组件变化不会影响到它的客户。Facade 模式有助于建立层次结构系统,也有助于对对象之间的依赖关系分层。Facade 模式可以消除复杂的循环依赖关系。这一点在客户程序与子系统是分别实现的时候尤为重要。在大型软件系统中降低编译依赖性至关重要。在子系统类改变时,希望尽量减少重编译工作以节省时间。用Facade 可以降低编译依赖性,限制重要系统中较小的变化所需的重编译工作。Facade模式同样也有利于简化系统在不同平台之间的移植过程,因为编译一个子系统一般不需要编译所有其他的子系统。
如果应用需要,它并不限制它们使用子系统类。因此你可以让客户程序在系统易用性和
通用性之间加以选择。

从整体上来看门面模式给我的感觉是,它对于使两层之间的调用粗颗粒化很有帮助,避免了大量细颗粒度的访问。这和 SOA 中的一些观点是相同的。