观察者设计模式在报警处理系统中的应用

尚 伟,刘志广,张 沫

(1.中国电子科技集团公司第五十四研究所,河北石家庄050081;2.河北文化信息资源共享中心,河北石家庄050011)

0 引言

耦合度是标识软件系统好坏的一个重要属性,软件系统中存在过多的耦合会使系统变得复杂,错误率增加,从而使系统难于更改和维护。过度的耦合不利于模块的设计和重用,为了提高模块化和封装性,应该尽量减少对象类之间的耦合。在系统设计过程中,特别是系统框架的设计过程中,降低软件系统的耦合性是改善软件系统的可维护性、可理解性和可扩展性的关键。采用合理的设计模式为目前改善软件系统耦合性的常用方法。

设计模式是按照建筑设计领域模式思想对软件设计领域的总结和归纳,对软件行业的发展有重要推动的作用。计算机科学中对设计模式的简单定义就是对于一类重复出现的问题的一种可重用的解决方案,在软件工程中一个设计模式对应解决一类软件设计问题。设计模式是成功的软件架构设计经验总结,是被实践证明的可复用的解决方案。设计模式解决了软件开发中有关对象的创建、结构和行为等一系列问题。如果多个项目有相同的问题背景,那么可以应用相同的设计模式加以解决。在软件设计中使用设计模式可以减少各个类之间的依赖和藕合,增强结构复用性,减少因变更所做的设计调整。观察者设计模式就是这样的一种低耦合设计技术。

1 观察者模式及其实现

观察者模式是一种行为性设计模式。它定义了一个对象间一对多的信赖关系,当一个对象改变状态时,所有与它有信赖关系的对象都得到通知并自动更新。适用于以下的情况:①一个抽象的模型拥有2个方面,其中一个方面依赖于另一个方面。将这2个方面封装在独立的对象中,可以使它们各自独立地改变和复用;②一个对象改变时,也要改变其他对象,但不知道具体有多少对象需要改变;③一个对象必须通知其他对象自己状态的改变,而又不能假定其他对象是谁。使用观察者模式,可以减少目标和观察者对象间的耦合程度,并且这种模式支持广播通信,可以同时改变多个对象的状态。

1.1 模式原型

观察者模式定义了目标对象和观察者对象之间的一种一对多的依赖关系,当目标对象的状态发生了改变,它要能够把这一信息通知给所有依赖于它的观察者对象,而各个观察者对象根据通知信息来恰当地对自己的表现形式进行更新。观察者模式结构如图1所示。

图1 观察者模式结构

图1中目标类提供注册和删除观察者对象的接口;而观察者类为那些在目标发生改变时需获得通知的对象定义一个更新接口;当具体目标类的状态发生变化时,负责向它的各个观察者发送通知;具体观察者类存储有关状态,实现观察者的更新接口以使自身状态与目标状态一致。

1.2 耦合性消减分析

如果2个类的访问或通信是直接通过彼此调用实现的,这样2个类间的耦合关系就会非常紧密。根据图1中的结构可以看出,观察者模式中目标类与具体观察者类是通过观察者这个接口的方式实现彼此间通讯的,而具体观察者类是负责具体实现该接口以及函数的类,这种结构实现了接口与实现分离的策略。这样的设计也使得具体目标与具体观察者不直接关联,具体目标变化时通知观察者,只需通过注册的观察者接口完成更新操作(更新的具体实现在具体观察者类中),即具体目标类不需要知道具体观察者类,这样做降低了目标类与具体观察者类的耦合度。

1.3 模式的实现方法

观察者模式中目标与观察者是一对多的关系,在实际的程序设计中目标对象使用一个数组或链表成员变量来维护它的多个观察者对象。注册函数和删除函数是添加或删除观察者对象的接口。通知函数是当目标对象状态改变时通知它的所有观察者对象的接口。在目标对象的通知函数接口中常用数组或链表保存依赖于主题对象的观察者对象,同时在该接口中将对这些对象进行遍历,每遍历到一个观察者对象时就会调用它的更新函数接口。更新函数根据消息的类型使得观察者对象对目标对象的状态变化做出相应的更新。这样,目标对象的一个通知函数执行下来,它的所有观察者对象都更新了。

对具体目标类来说,它从基类(目标类)派生,在基类的基础上增加了自身的状态数据。当自身的状态数据发生变化时根据需要向观察者对象发送消息。具体的观察者对象存储自身状态,但往往这些状态是由观察者的目标类内容决定的。在逻辑上它们必须保持一致,观察者在实际的设计中往往设计成一个虚基类,更新函数是一个纯虚函数,这样才可以利用面向对象的多态性调用各个观察者接口的实现类的更新函数。所以具体的观察者类的一个重要任务就是实现接口(观察者的更新函数),所有具体观察者类的状态维护都靠它来完成。

2 应用实例

报警处理系统是管理和接收报警信息,根据报警事件制定和管理预案,完成报警事件处置的信息系统,其主要功能是报警信息处置管理、报警事件检索分析、管理和收发格式化信息、文书信息管理、预案管理、勤务通信和短信管理等。

2.1 问题分析

系统的用户需求可分为不变部分和易变部分。需求的不变部分:①信息的收发基本功能不变;②收发文的模板及其相应数据的表现形式稳定:这些模板都是长期实践保存下来的,被相应部门广泛使用的固定格式,一般不会轻易改变;③信息发送的操作方式相对稳定:都是选择固定的地址,再根据相应模板进行内容调整后进行发送。需求的易变部分有:用户界面易变,报警处理软件的开发者毕竟不是软件的使用者,那么软件开发者就必须去适应软件使用者对软件界面多变的要求,如何在满足使用者要求的同时最大程度地减少软件改写的开销成为必须解决的问题。

2.2 主体功能架构

报警处理系统的主体功能是报警事件的接收显示及处置。系统对于接收到的报警信息根据其地理坐标及相应属性显示在地图背景上,并利用声、光等辅助手段提示用户。用户发现报警后利用系统提供的界面可对报警事件进行处置(关联预案、通知相应部门、启动报警记录等),处置后的报警信息将在用户界面进行更新,取消闪烁并停止声、光提示。

系统中界面显示和业务处理功能相分离,外层界面依赖于业务功能模块,它们各自又可独立地改变和复用;此外,两部分中当一方改变时,也要通知并改变另一方,所以使用MVC(模型—视图—控制器)架构作为整体结构设计决策。系统中的视图部分用于显示模型状态、接收数据更新请求和发送用户请求给控制器。在工程中实例化为地图显示相关的类,它们完成报警信息的图上显示、启动闪烁、更新状态和停止闪烁灯操作。模型部分用于封装应用程序状态、响应状态查询、处理业务流程和通知业务状态更新。在工程中实例化为报警信息管理的相关数据类,它完成报警数据的库检索和报警数据的结构化等工作。控制器部分用于接收用户请求、调用模型响应用户请求和选择视图显示响应结果。工程中实例化为报警信息管理的诸多界面类,完成图上显示的控制以及报警信息的管理等操作。主体功能架构图如图2所示。

图2 主体功能架构

2.3 设计与实现

每个系统都有自己的特点,不能照抄照搬别人的设计模式,应该找到符合自己的系统设计,走出一条适合自己的开发之路。为了实现上述系统,并尽可能切断系统各模块之间的耦合,提高系统的扩展性,引入了观察者模式。系统的开发利用VC6.0工具,根据实际的情况设计中没有对观察者模式中目标类做继承关系的设计(应用中的Subject比较简单,没有复杂的层次关系,不需要专门抽象一层来)。下面对系统中的主要类的关系和结构进行说明。

系统中的类可以分为界面类、数据类和观察者类3种。对于每个功能模块来说,由于使用观察者接口,界面类的变化(比如使用控件的变化)不需要更改数据类,而数据类的变化(比如增加了一些新操作)也不需要更改相应的界面类。对象设计结构如图3所示。

图3 系统设计结构

系统设计结构图中,主控类聚合了文书管理、预案管理、报警管理和收发文管理4个窗口类。对于这4个功能模块来说设计结构相同,这里就不再重复叙述,仅对报警管理功能模块进行详细介绍。

报警信息管理数据类调用报警处置信息变动观察者类中的报警处置管理虚函数,间接调用报警信息管理界面类中报警处置相关的实现函数,报警信息管理界面类继承报警处置信息变动观察者类,是具体实现报警处置信息变动观察者类中虚函数操作的类,它利用接口(报警处置信息变动观察者类中的虚函数)调用报警信息管理界面类中的实现函数即可以实现报警目标的图上显示、报警处置和报警关闭对应界面的更新。

其中,报警处置信息变动观察者类在观察者模式中对应观察者类,它为其所观察的目标类的改变定义了更新的接口;报警信息管理界面类承担的是观察者模式中具体观察者类的职责,它是报警处置信息变动观察者类的子类,继承了父类的接口并实现了这个更新接口,此外它还存储报警的状态,利用更新接口使得自身状态与其观察的目标对象状态保持一致。报警信息管理数据类充当的是观察者模式中具体目标类和目标类二者的角色,它不仅提供对于观察者的注册和删除功能,还提供对注册的观察者状态进行获取、设置的功能,当报警状态因报警处置(结束报警)或接收报警(启动报警)而改变时,该类可获得状态并将状态的更改通知与之相关的观察者,完成报警信息管理界面类上的报警状态闪烁与否的更新。

2.4 讨论分析

虽然采用观察者模式具有诸如松耦合、易于复用和变更较少等优势,但该模式的使用需要注意如下问题:

①松偶合导致代码关系不明显,尤其是模式代码混入到参与类中来,而产生严重的代码分散问题,降低代码的可读性。不过,如果代码阅读者熟知观察者模式则代码理解上会更容易一些;

②如果一个Subject被大量Observer订阅的话,在广播通知的时候可能会有效率问题。毕竟通知只是简单的遍历,所以当存在大量观察者时,这种问题会凸显出来。这个时候往往意味着设计上可能存在缺陷,需要考虑修改设计,增加多个观察者接口;

③虽然观察者模式可以随时使观察者知道所观察的对象发生了变化,但是观察者模式没有相应的机制使观察者知道所观察的对象是怎么发生变化的。如果需要获得这种变化,则需要针对变化做出相应的处理,比如在观察者刷新函数(Update)中增加变化因素作为参数。

3 结束语

实践证明,观察者设计模式这种设计技术的采用提高了软件开发的效率,提高了系统的可重用性和可扩展性,降低了软件系统中模块间的耦合度。诚然,设计模式并不是万能的,但它提供了一种在开发人员和组织之间共享可使用解决方案的方法,这些解决方案是凝聚了很多设计者积累的知识和经验的最佳实践。采用适合自己的设计模式将能够敏捷地构建信息系统,更好更快地实现用户需求。

[1]ERICH G,RICHARD H,RALPH J,et al.Design Patterns:Elements of Reusable Object-Oriented Software[M].李英军,马晓星,蔡 敏,等译.北京:机械工业出版社,2007.

[2]吴善明,沈建京,刘 辉.浅析Observer模式在GIS软件设计中的应用[J].计算机工程与设计,2007,28(18):4532-4534.

[3]付登科,郝克刚,葛 玮.AOP改进观察者模式——实现关注点的分离[J].计算机应用(自然科学版),2005,25(S1):410-412.

[4]肖计划,刘海砚,张吉才.设计模式在地图制图软件开发中的应用[J].测绘工程,2008,17(5):4-7.

[5]王 宇,王 力,李增智,等.面向对象软件框架中的耦合性及其消解策略的研究[J].小型微型计算机系统,2003,24(10):1743-1746.

[6]李 进,师建东,周 琦.一种基于模式的应用网关设计[J].无线电工程,2009,39(9):1-2.