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

《基于软件开发下外观模式的改进研究》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、基于软件开发下外观模式的改进研究外观模式是使用频率较高的软件设计模式之一。针对标准外观模式所存在的问题，本文提出了两种外观模式改进方案并结合实例进行研究。通过引入抽象外观类，让系统具有良好的可扩展性，满足开闭原则;通过对外观类实施单例化，可以确保外观对象的唯一性，节约系统资源。1引言设计模式在软件开发中应用日益广泛，它们是前人经验的总结与积累，每一种模式均是在多个软件项目中被反复使用、被多数人知晓，且经过规范的分类编目和整理的面向对象设计经验的总结。外观模式是使用频率较高的软件设计模式之一，在软件开发中应用非常广泛。根据单一职

2、责原则，将一个大的软件模块(或子系统)进行分解可以降低整个系统的复杂性，提高单个模块(或子系统)的独立性和可复用性。通过引入外观角色，可以降低客户类与子系统类之间的耦合度，使之相互依赖关系降至最小，从而降低原有系统的复杂度。在没有外观角色的系统中，客户类需要与多个子系统类进行交互，系统耦合度较高;在引入外观角色之后，客户类只需要与外观类交互，再通过外观类间接调用子系统类，在外观类中封装了与子系统之间的复杂交互关系，从而降低系统的耦合度。但是，在标准的外观模式中存在两个问题：首先，标准外观模式没有提供抽象层，在增加、更换或者删除

3、子系统类时需要修改客户类或者外观类的源代码，违背了开闭原则;其次，外观类维持了对多个子系统类的引用，在系统运行时，外观对象势必会占用较多的系统资源，需要对外观对象的数量进行限制。2外观模式的改进方案针对标准外观模式存在的问题和缺陷，本文提出了相应的改进方案，包括引入抽象外观类以及对外观类实施单例化。2.1抽象外观类的引入为了让外观模式能够符合开闭原则，引入抽象外观类来对外观模式进行抽象化改进。客户端针对抽象外观类进行编程，将所有的具体外观类作为抽象外观类的子类，如果需要更改业务需求，无须修改原有外观类，只需要增加一个新的具体外

4、观类即可，由新的外观类来关联新的业务需求。通过使用配置文件，可以达到不修改任何源代码即可置换外观类的目的，如图1所示。2.2外观类的单例化在大多数情况下，为了节约系统资源，程序在运行时只需创建某个外观类的唯一实例。因此，可以将外观模式与单例模式联用，对外观类实施单例化，确保系统中只存在唯一一个外观对象并提供唯一的访问入口，可以降低系统资源的消耗。单例化后的外观类的结构如图2所示。在图2中，外观类Facade被设计为单例类，在其中定义了一个静态的Facade类型的成员变量instance，其构造函数为私有的(private)，并

5、通过一个静态的公有工厂方法getInstance()返回自己的唯一实例。3实例研究下面通过一个实例来说明如何在实际项目中使用改进后的外观模式。在某使用外观模式的文件加密模块的初始设计方案中，FileReader类用于读取待加密的源文件、FileWriter类用于保存加密之后的文件、Cipher类用于实现数据的加密，EncryptFacade是一个加密外观类，它通过调用三个业务类中的方法实现文件读取、加密和保存的完整流程。3.1抽象化改进如果需要将原系统中的加密类Cipher改为NeL等格式的配置文件中，更换具体外观类时只需修改

6、配置文件，无须修改源代码，符合开闭原则。3.2单例化改进为了节省系统资源，可以将EncryptFacade设计为单例类，改进之后的结构如图4所示。通过对外观类实施单例化，可以确保系统中有且仅有一个EncryptFacade类的实例，避免生成多个EncryptFacade对象，节约系统资源。4结束语外观模式是一种使用频率非常高的设计模式，在软件开发中应用广泛。针对标准外观模式存在的不足，本文提出了两种外观模式的改进方案：第一种方案通过引入抽象外观类，使得系统在增加、删除或者更换子系统类时无须修改已有类的源代码，可以对抽象外观类进

7、行扩展来适应设计方案的改变，让系统满足开闭原则;第二种方案通过对外观类单例化，将外观模式与单例模式联用，确保在系统中只存在外观类的唯一实例，节约系统资源。通过上述改进，可以提高外观模式的适用性和有效性。：刘伟丁长松：电子技术与软件工程2015年22期