-- 摘要
2019年8月，我司承接了某市医疗集团，智慧药房项目，该项目主要为集团下属36家社区卫生服务中心提供药品统一目录管理、药品集中采购、库存管理、处方合理用药审核、药品配发、自动化发药设备驱动提供软件支撑。在该项目中我担任了软件架构设计师一职，主要负责该项目的软件架构设计工作。本文以智慧药房项目为例，主要论述了设计模式在项目中的具体应用，在处方审核模块中，采用了适配器模式，将不同HIS发过来的数据进行统一适配；在设备协同模块，采用了桥接模式，满足同一种业务不同设备的不同驱动方式，在设备报警模块采用了观察者模式，将设备PLC等底层异常情况，通过事件通知UI层，实现了UI层和底层模块的解耦，通过使用这些设计模式，提高了软件的设计质量和开发效率，最终项目成功上线，并获得了用户一致好评
-- 背景
根据深化医药卫生体制改革规范药求，推进药品集中采购，增加药品的供应保障能力，严格监督管理，保障药品的用药安全，所有医疗机构开出的处方，必须通过处方审核后，方可进入划价计费环节，未经审核的处方，不得进行计费和配发。2019年8月，我司承接了某医疗集团智慧药房项目，该项目为医疗集团下属36家社区卫生服务中心提供软件支持，主要分为药品供应模块、药房管理模块、处方用药审核模块、药品配发模块、设备协同模块。药品供应模块负责药品库存预警，供社区卫生服务中心药房对药品进行集中采购，并将药品发送到省采招平台；药房管理模块主要进行一些基础信息的维护，及关注药品的库存管理，药品批号跟踪；处方用药审核模块，负责对医生开出的药品进行合理用药审核，将不合理的处方审核结果返回给医生，提醒医生修改处方；药口中配发模块，负责将处方中的药品进行调配，打印用法用量标签，确认发药后扣减相应的库存；设备协同模块主要是驱动药房中的一些自动化发药设备，将要药品信息发给设备上位机，根据设备药品的效期进行排序，通过上位机程序调用下位机，驱动设备出药。在该项目中我担任软件架构设计师职务，主要负责软件的架构设计及中间件等技术的选型工作。
--问题回答，根据提干来
设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间试验和总结出来的最佳实践。是一套被反复使用的，多数人知晓的代码设计经验的总结。使用设计模式是为了重用代码，让代码更容易被他人理解，保证代码的可靠性，每个设计模式都在重复不断的描述了重复发生的问题，这也是设计模式能被广泛使用的原因。设计模式分为三大类型：创建型模式、结构型模式、行为型模式。创建型模式：提供了一种在创建对象的方式，使得创建对象更加灵活，常见的模式有工厂模式、抽象工厂模式、单例模式等5种。结构型模式：负责处理类或对象之间的关系，常用的结构型设计模式有外观模式、桥接模式、装饰模式等7种模式，行为型模式：关注对象之间的通信，常用的行为型模式有观察者模式、中介模式、策略模式等11种模式。这些设计 方法都是经过反复使用的成熟方法，对优化软件结构，提高软件质量具有重要的 指导意义。
--简介--中间过度作用
在智慧药房项目开发过程中，综合使用了多种设计模式，本文主要介绍适配器模式、桥接模式、观察者模式三种设计模式在该项目中的具体应用。
--介绍三个模式的应用
适配器模式：属于结构型设计模式，将一个接口转成用户希望得到的另一个接口，使得原本不兼容的两个接口可以协同工作。在智慧药房项目中，需要从院内信息系统（HIS）中同步数据，不同的社区卫生院他们所用的系统有所不同，这样他们在给我们传处方数据的时候，格式不同，有用WebService 有用 Restful 的，他们的字段名称也不相同，而且每家社区服务中心，他们所用的药品编码也各不相同，导致同一个药品进入我们系统后，会产生多条药品数据，在药品采购时，不知道选哪一条数据，给用户带来了困扰、增加了工作量。由于我们系统内部接口是固定的，而且接口协议、内容和HIS对接不上。后来我使用了适配器模式，将不同的HIS接口通过适配器，转成共同的数据格式和药品编码，再传给审方模块、配发模块。通过将医院HIS系统和我们系统的接口适配，解决了两边系统接口、数据不兼容问题。
桥接模式：属于结构型设计模式，我觉得桥接模式是对依赖倒置设计原则的一个很好应用，将类的抽象部分和实现部分分离，使得他们可以独立变化，实现二者的解耦。该项目中，用到了许多发药设备，这些发药设备由上位机驱动下位机程序实现设备出药，不同的设备下位机的实现不同，欧母龙PLC，有些是汇川PLC，也有西门子的等等。这种现象使得同种行为如驱动设备出药，会带来很多种不同的实现，设备多了会带来类爆炸，不同的设备上，业务是相同的，比如获取处方数据，点击确认出药按钮，驱动下位机出药，将变化点进行了隔离，在驱动下位机的实现时，使用了桥接模式。定义了IDevice驱动下位机的接口类，在里面定义一些驱动方法 DrugAssign()，同时根据不同的设备定义了不同的实现 OmronDeviceImpl，inovanceDeviceImpl，SiemensDeviceImpl，实现了 DrugAssign方法，分别调用不同的下位机命令。系统运行时，根据当前的设备，选择相对应的实现。实现了抽象和实现的解耦。
观察者模式：跟架构风格里的隐式调用风格有点相同，属于行为型模式，定义对象间的一种一对多的关系，当一个对象发生状态变化时，所有依赖它的对象都得到相应的通知并自动更新。在上位面上我们使用了观察者模式，上位机驱动类中定义了委托事件，业务系统监听这个事件。将药盒卡在槽位里，XX出药口马达停止工作，指示灯不亮待作为主题，当底层下位面产生异常报警时，将消息发给监听事件的观察者，界面将收到的异常信息展现在界面上，提醒用户去做相应的措施，观察者模式将消息的产生和订阅者进行了解耦，让双方都依赖于抽象，而不是依赖于具体，从而使得各自的变化都不会影响另一边的变化，方便维护、扩展和重用。
-- 结尾
项目于2019年8月启动到2020年10月历时14个月，圆满完成，顺利完成验收，并取得了客户的一致好评，该项目运行一年多，也出现过一些小的问题，由于医院使用的是集团内部局域网，与外网隔离，给排查问题及维护增加了困难，一次发药设备上的上位机不心小被药房老师删除后，不会重新安装操作，上报我司后，我们联系医院信息科老师，在信息科的老师协助下，对软件重新进行了安装，此次事件，导致了设备停止工作了几个小时，影响了药房发药效率。后来我司安排了1名售后维护该项目，这一年内也新增了一些发药设备，由于选用了合适的微服务架构，使得设备的接入及服务的扩展变得非常容易，在售后同事的协助下，系统至今运行稳定。该项目的成功，让我意识到了使用了设计模式的作用和价值，坚定了我对设计模式应用的信心，合理选择合适的设计模式，能够大大的提高了软件设计的复用方法，加快开发的进程，在项目中起到事半功倍的作用。经过这次项目，我也看到了自己身上的不足之处，在未来还会不断地更新知识，完善本系统的设计，使系统能够适应国家医改的变化需要，这是作为软件从业的我为之努力的动力和方向。