-- 摘要
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個月，圓滿完成，順利完成驗收，並取得了客戶的一致好評，
在項目開發期間也碰到了一些問題，比如由於一些同事對設計模式的理解和掌握層度不夠，使得一些不需要用設計模式的地方用了設計模式，增加了代碼的復雜度，也因此帶來了類爆炸問題，后來將代碼進行重構，並且加強了CodeReview，避免了此類事件的再次發生，提高了代碼的質量，項目至今運行一年多，系統至今運行穩定。該項目的成功，讓我意識到了使用了設計模式的作用和價值，堅定了我對
設計模式應用的信心，合理選擇合適的
設計模式，能夠大大的提高了軟件設計的復用方法，加快開發的進程，在項目中起到事半功倍的作用。我想這是值得每一位軟件從業人員為之努力的動力和方向。