-- 摘要
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名售後維護該項目，這一年內也新增了一些發藥設備，由於選用了合適的微服務架構，使得設備的接入及服務的擴展變得非常容易，在售後同事的協助下，系統至今運行穩定。該項目的成功，讓我意識到了使用了設計模式的作用和價值，堅定了我對設計模式應用的信心，合理選擇合適的設計模式，能夠大大的提高了軟件設計的複用方法，加快開發的進程，在項目中起到事半功倍的作用。經過這次項目，我也看到了自己身上的不足之處，在未來還會不斷地更新知識，完善本系統的設計，使系統能夠適應國家醫改的變化需要，這是作爲軟件從業的我爲之努力的動力和方向。