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

基于设计模式的医疗保险系统 摘要：设计模式已经成为软件开发领域的一个热门话题，该文引入了设计模式的基本原理，并以策略模式、适配器模式和视察者模式在医疗保险系统中的运用为例，阐述了这三种模式的原理，并用实例说明白运用设计模式为此系统带来的众多好处。 关键词：设计模式；医疗保险系统；策略模式；适配器模式；视察者模式 中图分类号：TP311文献标识码：A文章编号：1019-3044(2022)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 策略模式 在系统中，当用户要对单位效益进行结算时，系统为用户供应日报、月报、年报3种形式。根据传统的思想，若不运用Strategy模式，统计报表的程序代码大致结构如下： void Count:Choice( ) Public: Switch(StrategyType) Case DayStrategy: DoDayStrategy( ); Break; Case MonthStrategy: DoMonthStrategy( ); Break; 但是这种算法是不行取的它特别困难，不仅要维护一个switchcased的条件分支语句，还必需供应适应各种不同操作的响应方法，如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 适配器模式 在此系统中，我们要时刻跟踪数据的改变，依据数据的改变，全部依靠于它的柱状、表格、饼状等对象都刚好的得到通知，并做出相应的变更，最终在用户界面中呈现给用户。在以前，显示对象根据肯定的查询频率对数据对象进行刷新，重新获得数据，同时将变更的数据信息存入数据库中，最终在用户界面中以多种形式呈现给用户。但是由于数据的改变频率不同，我们很难设定一个适当的查询频率，查询的频率过少不能刚好的将变更的数据显示出来，过多则奢侈了资源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 LanguageM.New York:Oxford University Press,11017. 3 Gamma E,Helm R,Johnson R,et al.Design Patterns:Elements of Reusable Object Oriented SoftwareM.Addison Wesley,11015. 4 辛振铭,孙耀,杨志强.基于设计模式的在线购物系统的应用与探讨J.信息技术,2022(4):141-144. 第9页 共9页第 9 页 共 9 页第 9 页 共 9 页第 9 页 共 9 页第 9 页 共 9 页第 9 页 共 9 页第 9 页 共 9 页第 9 页 共 9 页第 9 页 共 9 页第 9 页 共 9 页第 9 页 共 9 页