专业咨询
致力推进中国医疗卫生信息化

【吴坤专栏】如何开发高性能医疗信息系统(程序设计篇之二)

【编者按】

医疗信息化建设最主要的任务是规划、设计、开发以及部署医疗信息系统。如何开发设计性能良好的医疗信息系统,对于提高医院临床科室的工作效率和医疗信息化工作水平而言至关重要。

在本系列文章中,笔者将围绕“如何开发性能良好的医疗系统软件”这一主题,并结合自身工作经历,分别从软件系统架构设计、程序开发设计、数据库设计开发、项目管理、典型案例等几个方面分享和总结相关经验和教训。

来源:HIT专家网       作者:华中科技大学同济医学院附属同济医院 吴坤

接上篇:【吴坤专栏】如何开发高性能医疗信息系统(程序设计篇之一)

上一篇文章中,笔者结合自身实践,就如何开发高性能医疗软件所需要遵循的规范和法则做了概括性介绍。与互联网等其他行业相比,医疗业务有其自身特点:一方面并发量不高,大多数软件应用在内网,对互联网公开环境安全性要求不高,或者说安全性要求更多体现在其他方面;另一方面是内外环境变化快,医疗行业政策趋势和医疗机构本身处于一个快速变化的环境中,医疗软件需要具备强大的拓展性和适应性,能够适应内外环境变化。

所以根据医疗业务特性,在开发医疗软件时,不需要设计太过先进和复杂的系统架构,而是要设计具备良好拓展性和适应性的软件。在系统设计时,运用好设计模式,是设计出良好拓展性和适应性软件的有效方法。因此,从本篇章开始,笔者将主要介绍设计模式相关知识,以及在医疗软件系统设计中的运用。

在探讨设计模式的应用之前,首先对设计模式相关背景做简单介绍。我们知道,生产任何商品都有一套完整的流程和步骤。以构建房屋为例,建筑设计师首先会根据房屋用户的需求设计出方案蓝图,然后建筑工程师再按照流程一步步完成房屋的建造工作。在此过程中,设计师和工程师都是按照一定的流程和方案来完成各自工作,最终建成设计优美、结构合理的建筑,我们可以把他们所遵循的这套流程和方法称为设计模式。试想,如果没有设计模式作为指导,那么建造出的房屋可能会出现高低不齐、空间不均,难以承受任何“风吹草动”。

设计模式是人们在长期实践中总结出来的经验和方法论。同样,在软件设计领域也存在相应的软件设计模式。可以说,软件设计模式是大量软件开发人员经过相当长时间的试验后,所总结出来的解决软件开发过程中的一般问题的解决方案,也代表了最佳软件设计实践。在软件设计时,软件工程师如果遵循和依照合理的设计模式来开发,往往能起到事半功倍的效果,可以很好地设计出性能高、拓展性好的软件。

根据具体应用场景和所需要解决的问题,软件设计模式大致可分为三大类23种,具体分类如下:

单例模式

单例模式的定义:程序一个类只有一个实例,且该类能自行创建这个实例。

从定义可看出单例模式有以下几个特点:

   (1)单例类只有一个实例对象;

   (2)该单例对象必须由单例类自行创建;

   (3)单例类对外提供一个访问该单例的全局访问方法。

单例模式的结构:

单例模式结构图很好地描述了单例模式的实现方法。通常,对于程序中普通类而言,其构造方法是公有的,外部类可通过“new 构造函数()”生成多个实例。但是,如果将类的构造函数设为私有的,外部类就无法调用该构造函数,也就无法生成多个实例。单例模式正是运用这一特点,在类内部自身定义一个静态私有实例,并向外提供一个静态的公有函数用于创建或获取该静态私有实例。

单例模式有几种典型的应用场景

(1)应用程序中,某类只要求生成一个对象的时候,如科室主任、患者基本信息等。

(2)当对象需要被共享的场合。由于单例模式只允许创建一个对象,共享该对象可以节省内存,并加快对象访问速度。如 Web 中的配置对象、数据库的连接池等。

(3)某个类需要频繁实例化和频繁的销毁,如多线程的线程池、网络连接池等。

原型模式

原型模式的定义:用一个已经创建的实例作为原型,通过复制该原型对象来创建一个和原型相同或相似的新对象。

用这种方式无需了解对象创建的具体细节,对象的创建过程非常高效。

原型模式的结构:

抽象原型类中定义了“clone()”方法,具体原型类实现了该方法,该方法定义了创建对象的具体细节,外部访问类需要创建对象是,直接调用具体原型对象的“clone()”方法即能实现对象的创建。

原型模式的应用场景

(1)对象之间相同或相似,只有个别的属性不同。

(2)对象的创建过程比较麻烦,但复制过程比较简单。

工厂方法模式

工厂方法模式的定义:定义一个创建产品对象的工厂接口,将产品对象的实际创建工作推迟到具体工厂实现类当中,实现了创建型模式中的“创建与使用相分离”的特点。

主要优点:

(1)用户只需要知道具体工厂的名称就可得到所要的产品,无须知道产品的具体创建过程;

(2)在系统增加新的产品时,只需要添加具体产品类和对应的具体工厂类,无需对已存在的工厂类进行修改,满足开闭原则;

主要缺点:每增加一个产品就要增加一个具体产品类和一个对应的具体工厂类,随着产品类和工厂类数量的增加,系统复杂度也将随之增大。

抽象工厂模式

抽象工厂模式的定义:提供一个创建一组相关或相互依赖对象的接口,且访问类无须指定所要产品的具体类就能得到同族的不同等级的产品的模式结构。

抽象工厂模式是工厂方法模式的升级版本,工厂方法模式只生产一个等级类别的产品,而抽象工厂模式可生产多个等级多个类别的产品。

结构图如下:

从结构图可看出,抽象工厂模式是围绕一个超级工厂创建其他工厂,其他工厂再创建各自类别的产品。

抽象工厂模式除具有工厂方法模式的优点外,还具有如下优点

(1)可以在类的内部对产品族中相关联的多等级产品共同管理,而不必专门引入多个新的类来进行管理。

(2)当增加一个新的产品族时,不需要修改已存在的产品相关的程序代码,满足开闭原则。

缺点:当产品族中需要增加一个新的产品时,所有的工厂类都需要进行修改。

应用场景

(1)当需要创建的对象是一系列相互关联或相互依赖的产品族时,如医院系统内部不同数据库的访问连接、不同系统中的患者信息等。

(2)系统中有多个产品族,但每次只使用其中的某一族产品。

(3)系统中提供了产品的类库,且所有产品的接口相同,客户端不依赖产品实例的创建细节和内部结构。

建造者模式

建造者模式的定义:指将一个复杂对象的构造与它的表示分离,使同样的构建过程可以创建不同的表示,这样的设计模式被称为建造者模式。它是将一个复杂的对象分解为多个简单的对象,然后一步一步构建而成。它将变与不变相分离,即产品的组成部分是不变的,但每一部分可灵活选择。

结构图如下:

从结构图可看出,每个具体的建造类实现各自的产品组装工作,每个步骤自行定义,非常灵活。

主要优点:

(1)各个具体的建造者相互独立,有利于系统的扩展。

(2)客户端不必知道产品内部组成的细节,便于控制细节风险。

主要缺点:

(1)产品的组成部分必须相同,限制了其使用范围。

(2)如果产品的内部变化复杂,该模式会增加很多的建造者类。

建造者模式创建的是复杂对象,其产品的各个部分经常面临着剧烈变化,但将它们组合在一起的算法逻辑却相对稳定,所以通常适用于如下场景

 (1)创建的对象较复杂,由多个部件构成。各部件面临着复杂的变化,但构件间的建造顺序是稳定的。

(2)创建复杂对象的算法逻辑独立于该对象的组成部分以及它们的装配方式,即产品的构建过程和最终的表示是独立与具体产品的。

创建型设计模应用案例

创建型设计模式在医疗软件系统中有很多应用场景,本文通过一个抽象工厂模式的应用事例,介绍创建型设计模式在医疗软件系统中的应用。

医院内与患者相关的数据信息常常分布存在不同的数据库中,这是由于医院因业务不同通常会采购不同公司的软件产品。比如,医院有门诊、住院、检验、检查等不同软件系统,这些系统采用的数据库和相关技术可能也不相同。但是在日常业务中,对于数据的操作却非常类似。比如,通过ID号查询患者相关信息,以及写入或者修改数据信息等。

对于上述应用场景,可以运用工厂方法模式来构建相应类,实现数据库的“连接生成”和“访问操作”相分离,也就是创建型模式中类的“创建”和“使用”相分离。

如上图所示,首先抽象出一个数据库访问操作类IAccessDb,其内部封装了数据库操作方法:通过患者id查找信息和数据修改方法“getInformationById(String id)”和“executeSql(String sql)”。InpatientDd、OutpatientDb和LabDb为住院、门诊和检验系统数据库访问操作类,分别继承和实现了IAccessDb中的方法,以实现对各自系统数据的访问操作。

同时,设置一个抽象类DbAccessFactory,其内部封装了一个数据库访问操作类生成方法:createDbAccess()、InpatientDbFactory、OutpatientDbFactory和LabDbFactory为具体的工厂类,继承并实现DbAccessFactory类中的方法。在程序实现时,根据需要,可通过生成相应的工厂类来生成需要的数据连接操作类,以隔离不同数据库差异带来的问题。

【作者简介】

吴坤,计算机专业硕士,华中科技大学同济医学院附属同济医院信息中心软件工程师。专业计算机程序员,医疗信息技术推广者,积极参与社会活动,热衷于以信息技术提高医疗行业服务质量和改善患者就医体验。

小助手二维码

想加入HIT专家网专业交流群吗?请添加“HIT专家网”小助手微信好友

(请务必注明姓名、单位名称、职务、主管技术或产品领域等实名信息)

【责任编辑:孙鹏】

赞(9)

评论 抢沙发

评论前必须登录!

 


未经允许不得转载:HIT专家网 » 【吴坤专栏】如何开发高性能医疗信息系统(程序设计篇之二)
分享到: 更多 (0)