基于软件开发下外观模式的改进研究
外观模式是使用频率较高的软件设计模式之一。针对标准外观模式所存在的问题,本文提出了两种外观模式改进方案并结合实例进行研究。通过引入抽象外观类,让系统具有良好的可扩展性,满足开闭原则;通过对外观类实施单例化,可以确保外观对象的唯一性,节约系统资源。
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期
下一篇:软件工程开发的现状及发展的探讨