基于软件开发下外观模式的改进研究

　　外观模式是使用频率较高的软件设计模式之一。针对标准外观模式所存在的问题，本文提出了两种外观模式改进方案并结合实例进行研究。通过引入抽象外观类，让系统具有良好的可扩展性，满足开闭原则;通过对外观类实施单例化，可以确保外观对象的唯一性，节约系统资源。

　　1 引言

　　设计模式在软件开发中应用日益广泛，它们是前人经验的总结与积累，每一种模式均是在多个软件项目中被反复使用、被多数人知晓，且经过规范的分类编目和整理的面向对象设计经验的总结。

　　外观模式是使用频率较高的软件设计模式之一，在软件开发中应用非常广泛。根据单一职责原则，将一个大的软件模块(或子系统)进行分解可以降低整个系统的复杂性，提高单个模块(或子系统)的独立性和可复用性。通过引入外观角色，可以降低客户类与子系统类之间的耦合度，使之相互依赖关系降至最小，从而降低原有系统的复杂度。在没有外观角色的系统中，客户类需要与多个子系统类进行交互，系统耦合度较高;在引入外观角色之后，客户类只需要与外观类交互，再通过外观类间接调用子系统类，在外观类中封装了与子系统之间的复杂交互关系，从而降低系统的耦合度。

　　但是，在标准的外观模式中存在两个问题：首先，标准外观模式没有提供抽象层，在增加、更换或者删除子系统类时需要修改客户类或者外观类的源代码，违背了开闭原则;其次，外观类维持了对多个子系统类的引用，在系统运行时，外观对象势必会占用较多的系统资源，需要对外观对象的数量进行限制。

　　2 外观模式的改进方案

　　针对标准外观模式存在的问题和缺陷，本文提出了相应的改进方案，包括引入抽象外观类以及对外观类实施单例化。

　　2.1 抽象外观类的引入

　　为了让外观模式能够符合开闭原则，引入抽象外观类来对外观模式进行抽象化改进。客户端针对抽象外观类进行编程，将所有的具体外观类作为抽象外观类的子类，如果需要更改业务需求，无须修改原有外观类，只需要增加一个新的具体外观类即可，由新的外观类来关联新的业务需求。通过使用配置文件，可以达到不修改任何源代码即可置换外观类的目的，如图1所示。

　　2.2 外观类的单例化

　　在大多数情况下，为了节约系统资源，程序在运行时只需创建某个外观类的唯一实例。因此，可以将外观模式与单例模式联用，对外观类实施单例化，确保系统中只存在唯一一个外观对象并提供唯一的访问入口，可以降低系统资源的消耗。单例化后的外观类的结构如图2所示。

　　在图2中，外观类Facade被设计为单例类，在其中定义了一个静态的Facade类型的成员变量instance，其构造函数为私有的(private)，并通过一个静态的公有工厂方法getInstance()返回自己的唯一实例。

　　3 实例研究

　　下面通过一个实例来说明如何在实际项目中使用改进后的外观模式。

　　在某使用外观模式的文件加密模块的初始设计方案中，FileReader类用于读取待加密的源文件、FileWriter类用于保存加密之后的文件、Cipher类用于实现数据的加密，EncryptFacade是一个加密外观类，它通过调用三个业务类中的方法实现文件读取、加密和保存的完整流程。

　　3.1 抽象化改进

　　如果需要将原系统中的加密类Cipher改为NewCipher，势必会导致外观类EncryptFacade源代码发生修改，违背开闭原则。通过引入抽象外观类，重构后的系统设计方案如图3所示，在图3中使用了基于衍型的模式标注方法SBPN (Stereotype Based Pattern Notation)来对结构图中的设计模式信息进行标注。

　　在图3中，客户类Client针对抽象外观类AbstractEncryptFacade进行编程，可将具体外观类类名存储在XML等格式的配置文件中，更换具体外观类时只需修改配置文件，无须修改源代码，符合开闭原则。

　　3.2 单例化改进

　　为了节省系统资源，可以将EncryptFacade设计为单例类，改进之后的结构如图4所示。

　　通过对外观类实施单例化，可以确保系统中有且仅有一个EncryptFacade类的实例，避免生成多个EncryptFacade对象，节约系统资源。

　　4 结束语

　　外观模式是一种使用频率非常高的设计模式，在软件开发中应用广泛。针对标准外观模式存在的不足，本文提出了两种外观模式的改进方案：第一种方案通过引入抽象外观类，使得系统在增加、删除或者更换子系统类时无须修改已有类的源代码，可以对抽象外观类进行扩展来适应设计方案的改变，让系统满足开闭原则;第二种方案通过对外观类单例化，将外观模式与单例模式联用，确保在系统中只存在外观类的唯一实例，节约系统资源。通过上述改进，可以提高外观模式的适用性和有效性。

　　作者：刘伟 丁长松 来源：电子技术与软件工程 2015年22期