基于设计模式的医疗保险系统

摘要：设计模式已经成为软件开发领域的一个热门话题，该文引入了设计模式的基本原理，并以策略模式、适配器模式和观察者模式在医疗保险系统中的使用为例，阐述了这三种模式的原理，并用实例说明了使用设计模式为此系统带来的众多好处。

关键词：设计模式；医疗保险系统；策略模式；适配器模式；观察者模式

中图分类号：TP311文献标识码：A文章编号：1009-3044(2011)08-1804-03

在系统开发的过程中，要建一个功能齐全又易于维护的系统，就必须有一套具有高度灵活性和复用性的系统设计。一个好的系统设计有很大一部分都依赖于对过去成功开发案例的借鉴，而设计模式的引入正是将其他项目开发中总结的经验和自身项目的实际情况相结合起来[1]。正确的引入设计模式，还可以吸收模式中的精华，为设计出一套功能齐全，易于维护而且复用性高的系统打下坚实的基础。

在开发医疗保险系统的过程中，遇到了很多以前经常出现或者曾经出现过的问题。套用原有的、经过证实的解决方案是最好的选择。通过重用已经建立起来的设计模式，可以从中吸收他人的程序设计开发经验，同时也不必为程序设计中重复发生的简单问题重复的寻求答案。

1 设计模式

1.1 设计模式的基本概念

许多著名的研究者都给出了设计模式的定义，其中有一个共同的主题：特定上下文环境下，问题解决方案的重复出现。

Erich Gramma等在他们编写的《设计模式》中指出“设计模式是被用来在特定场景下解决一般设计问题的类和相互通信的对象描述[2]。”他们总结了以往程序设计的经验，使得开发者再次遇到类似的问题时可以直接使用模式，准确高效的解决问题。

尽管Alexander的设计模式和Erich Gramma等人在软件开发中的设计模式有着学科方向上的差异，但是这两者都是在观察已有系统的基础上，发现其中的模式，都有描述模式的模板，都是用自然语言和许多例子而不是用形式语言来描述模式，都给出了每个模板后面的原理。

设计模式使设计人员可以更加简便的复用或者改进以往成功的设计，也可以有效的处理需求变更，减少各个类之间的耦合。一般而言，一个模式有四个基本要素[3]：

1）模式名称：用一两个词来描述模式的问题、解决方案和效果。便于开发者讨论模式并在编写文挡时使用它们，也便于开发者和其他人交流思想及设计成果。

2）问题：描述了应该在何时使用模式，它解释了设计问题和问题存在的前因后果，它可能描述了特定的设计问题，也可能描述了导致不灵活设计的类或对象结构。有时候问题部分会包括使用模式必须满足的一系列先决条件。

3）解决方案：描述设计的组成成分、它们之间的相互关系及各自的职责和协作方式。

4）效果：描述了模式应用的效果及使用模式应权衡的问题

1.2 怎样选择设计模式

要在从众多的设计模式中找出一个针对特定设计问题的模式也是不容易的。为此，本文给出简单的选择设计模式的步骤。

1）给所要解决的问题划分一个适当的类型；

2）根据问题类型从所有此类型的设计模式中选择合适的设计模式；

3）找出所要解决问题与所选择设计模式的相识点，在所要解决的问题区域内考虑元素对应于模式中的类是否合适，如不合适重新选择模式。

2 医疗保险系统

医疗保险系统以投保对象、医疗机构（医院、药店）、医保中心、资金机构作为业务主体，通过医保业务管理、医疗机构管理、信息交换、系统维护、医疗机构的消费管理等系统功能，全面地实现医保管理的自动化和科学化。同时也应该及时地向管理者和决策者提供医疗保险的各种信息。

医疗保险系统要实现的功能很多，无论是针对医院的医疗保险就诊费用结算还是来自区县医保办的医疗费现金报销，以及保费划拨审核和个人帐户维护管理应用都是围绕医保中心的数据库进行交易。此系统不仅要能支持多家药店和多家医院的使用，还要支持各个用户保险金的登记、统算等功能，要能及时的向医保部门提供用户的各项信息。更重要的是，系统要具备可扩展性和灵活性。新的药店或医院可能加入，系统功能的添加、修改和删除应尽量做到简单、易行，因为各项功能随时会因为政策的改变而需要修改。修改代码时也应该尽量遵循不波及其他模式的原则，以减少大范围的修改。

3 设计模式在医疗保险系统中的应用

在医疗保险系统中，实现的功能齐全，在界面多（社保单位、医院、药店等等），关联关系复杂。设计模式恰当的运用，能使系统结构清晰，功能繁杂而不混乱。根据设计模式在医疗保险系统中的应用，分析其中几种重要的设计模式。

3.1 策略模式（STRATEGY）

在系统中，当用户要对单位效益进行结算时，系统为用户提供日报（DayStrategy）、月报（MonthStrategy）、年报（YearStrategy）3种形式。按照传统的思想，若不使用Strategy模式，统计报表的程序代码大致结构如下：

void Count::Choice( )

{ …………

Public:

Switch(StrategyType)

{Case DayStrategy:

DoDayStrategy( );

Break;

Case MonthStrategy:

DoMonthStrategy( );

Break;

…………

} }

但是这种算法是不可取的它非常复杂，不仅要维护一个switch—cased的条件分支语句，还必须提供适应各种不同操作的响应方法，如DoDayStrategy( )、DoMonthStrategy( )等。使用这种算法，Count必须能够适应各种不同的情况，要记录不同时刻下的状态，这也会加大以后维护工作的工作量，给日后的维护工作带来一定的困难。

策略模式定义一系列的算法，把它们一个个封装起来，而且使它们可以相互替换。本模式使得算法可以独立于使用它的客户而变化[3]。当不同的行为堆砌在一个类中时，很难避免使用条件语句来选择合适的行为。将行为封装在一个个独立的Strategy类中则消除了这些条件语句。通过使用策略模式，可以避免以前控制一切、处理一切的算法结构。以下为系统应用Strategy模式的结构如图1所示。

在图1中，Count和Strategy相互作用来实现选定的算法。Strategy中定义了所有支持算法的公共接口，Count使用此接口，根据用户的选择不同即p不同，来调用DayStrategy、MonthStrategy、YearStrategy定义的算法。使用策略模式后，只要短短几条语句就可以完成任务，程序变的比以前更简单而且更直接：

Class Count::Choice( ){

………….

Private:

Strategy*p;

Public:

If(p!=NULL){

p->Compose( );

} ……

}

3.2 适配器模式（ADAPTER)

适配器模式在此系统中用到的次数最多，举一例说明，用户对单位效益进行结算后以曲线图的形式呈现给客户。结算曲线图主要是由点、直线和曲线三种图形组成。为了实现结算曲线图的功能，我们先创建一个Shape类，然后派生出表示点、直线的类，分别用point和line表示。如图2所示。

接着还需要实现曲线的显示，为了完成曲线的显示，面临的任务必须从Shape类中派生出一个表示曲线的类，为这个类编写Display和Undisplay，但是此项工作非常复杂。幸运的是，我们在以前的系统开发中曾遇到过类似的问题，已经编写过一个Curvedo类来处理曲线的显示，如图3所示。

但是，因为Shape和Curvedo接口不兼容所以系统不能直接使用类Curvedo。此时，选用适配器模式，可以解决系统接口不兼容的问题。适配器使得原本由于接口不兼容而不能在一起工作的那些类可以一起工作。即通过适配器模式可以将类的不符合客户要求的接口转换成客户需要的一个新接口，从而使原本接口不匹配而无法在一起工作的两个类能连接在一起。创建一个派生自Shape类的新类Curve，用在Shape和Curvedo接口之间进行匹配。使用适配器后系统结构图如图4所示。

Adapter模式的实现程序：

Class Curve: public Shape{

………..

Private:

Curvedo *p:

……….

Curve:: Curve( ){

……….

P=new Curvedo;

}

Void Curve::display( ){

p->undo( );

}

}

3.3 观察者模式（OBSERVER）

在此系统中，我们要时刻跟踪数据的变化，根据数据的变化，所有依赖于它的柱状、表格、饼状等对象都及时的得到通知，并做出相应的改变，最后在用户界面中呈现给用户。在以前，显示对象按照一定的查询频率对数据对象进行刷新，重新获取数据，同时将改变的数据信息存入数据库中，最后在用户界面中以多种形式呈现给用户。但是由于数据的变化频率不同，我们很难设定一个适当的查询频率，查询的频率过少不能及时的将改变的数据显示出来，过多则浪费了资源[4]。

根据观察者模式的定义，在对象间建立一种一对多的依赖关系，当一个对象的数据发生改变时，所有依赖于它的对象都得到通知并被自动更新。如何能使显示对象及时的获得准确的显示数据呢？这需要数据对象在发生变化时，能使所有依赖于它的对象都能及时的被通知，并及时的对数据进行更新。而采用Observer模式就可以在需要的时候自动更新显示对象。系统应用Observer模式的结构图如图5所示。

在Subject类中包含Attach( )和Detach( )。其中Attach( )将给定的观察者对象Tabdisplay、Bardisplay、Cirdisplay添加到观察者的列表中，Detach( )则在必要时从自己观察者的列表中移除出已经存在的观察者对象。通过观察者将它们自己注册或删除到Subject类中，从而确定了所有的观察者对象。当ConcreteSubject发生可能导致其观察者与其本身状态不一致的改变时，通过Subject类中的Notify( )立即向观察者列表中所有的观察者发出通知，在得到一个具体目标的改变通知后，Tabdisplay、Bardisplay、Cirdisplay对象调用其中的Update( )，从而使观察者的状态和目标对象的状态保持一致。

4 结束语

本文比较详细的介绍了Strategy、Adapter、Observer模式在医疗保险系统中的应用，这只是一部分除此之外我们还运用了Singleton、Decorator、MVC等设计模式，在此我就不一一介绍。事实证明，在医疗保险系统中运用了上述的设计模式，不论开发和维护都容易了很多，系统的可扩展性也比较好。很难想象在一个软件开发的过程中，没有利用任何设计模式会多花掉多少的人力和财力。但是，设计模式不用不合理可能会导致代码庞大，流程复杂，所以如果不是必须，不要滥用设计模式[4]。

参考文献：

[1] 马争,周艳,谢世波.设计模式在网管系统中的设计与实现[J].电子科技大学学报,2004,33(5):523-526.

[2] Christopher A.A Pattern Language[M].New York:Oxford University Press,1977.

[3] Gamma E,Helm R,Johnson R,et al.Design Patterns:Elements of Reusable Object Oriented Software[M].Addison Wesley,1995.

[4] 辛振铭,孙耀,杨志强.基于设计模式的在线购物系统的应用与研究[J].信息技术,2010(4):141-144.