外觀模式是使用頻率較高的軟件設計模式之一。針對標準外觀模式所存在的問題，本文提出了兩種外觀模式改進方案并結合實例進行研究。通過引入抽象外觀類，讓系統具有良好的可擴展性，滿足開閉原則;通過對外觀類實施單例化，可以確保外觀對象的唯一性，節約系統資源。
1 引言
設計模式在軟件開發中應用日益廣泛，它們是前人經驗的總結與積累，每一種模式均是在多個軟件項目中被反復使用、被多數人知曉，且經過規范的分類編目和整理的面向對象設計經驗的總結。
外觀模式是使用頻率較高的軟件設計模式之一，在軟件開發中應用非常廣泛。根據單一職責原則，將一個大的軟件模塊(或子系統)進行分解可以降低整個系統的復雜性，提高單個模塊(或子系統)的獨立性和可復用性。通過引入外觀角色，可以降低客戶類與子系統類之間的耦合度，使之相互依賴關系降至最小，從而降低原有系統的復雜度。在沒有外觀角色的系統中，客戶類需要與多個子系統類進行交互，系統耦合度較高;在引入外觀角色之后，客戶類只需要與外觀類交互，再通過外觀類間接調用子系統類，在外觀類中封裝了與子系統之間的復雜交互關系，從而降低系統的耦合度。
但是，在標準的外觀模式中存在兩個問題：首先，標準外觀模式沒有提供抽象層，在增加、更換或者刪除子系統類時需要修改客戶類或者外觀類的源代碼，違背了開閉原則;其次，外觀類維持了對多個子系統類的引用，在系統運行時，外觀對象勢必會占用較多的系統資源，需要對外觀對象的數量進行限制。
2 外觀模式的改進方案
針對標準外觀模式存在的問題和缺陷，本文提出了相應的改進方案，包括引入抽象外觀類以及對外觀類實施單例化。
2.1 抽象外觀類的引入
為了讓外觀模式能夠符合開閉原則，引入抽象外觀類來對外觀模式進行抽象化改進。客戶端針對抽象外觀類進行編程，將所有的具體外觀類作為抽象外觀類的子類，如果需要更改業務需求，無須修改原有外觀類，只需要增加一個新的具體外觀類即可，由新的外觀類來關聯新的業務需求。通過使用配置文件，可以達到不修改任何源代碼即可置換外觀類的目的`，如圖1所示。
2.2 外觀類的單例化
在大多數情況下，為了節約系統資源，程序在運行時只需創建某個外觀類的唯一實例。因此，可以將外觀模式與單例模式聯用，對外觀類實施單例化，確保系統中只存在唯一一個外觀對象并提供唯一的訪問入口，可以降低系統資源的消耗。單例化后的外觀類的結構如圖2所示。
在圖2中，外觀類Facade被設計為單例類，在其中定義了一個靜態的Facade類型的成員變量instance，其構造函數為私有的(private)，并通過一個靜態的公有工廠方法getInstance()返回自己的唯一實例。
3 實例研究
下面通過一個實例來說明如何在實際項目中使用改進后的外觀模式。
在某使用外觀模式的文件加密模塊的初始設計方案中，FileReader類用于讀取待加密的源文件、FileWriter類用于保存加密之后的文件、Cipher類用于實現數據的加密，EncryptFacade是一個加密外觀類，它通過調用三個業務類中的方法實現文件讀取、加密和保存的完整流程。
3.1 抽象化改進
如果需要將原系統中的加密類Cipher改為NewCipher，勢必會導致外觀類EncryptFacade源代碼發生修改，違背開閉原則。通過引入抽象外觀類，重構后的系統設計方案如圖3所示，在圖3中使用了基于衍型的模式標注方法SBPN (Stereotype Based Pattern Notation)來對結構圖中的設計模式信息進行標注。
在圖3中，客戶類Client針對抽象外觀類AbstractEncryptFacade進行編程，可將具體外觀類類名存儲在XML等格式的配置文件中，更換具體外觀類時只需修改配置文件，無須修改源代碼，符合開閉原則。
3.2 單例化改進
為了節省系統資源，可以將EncryptFacade設計為單例類，改進之后的結構如圖4所示。
通過對外觀類實施單例化，可以確保系統中有且僅有一個EncryptFacade類的實例，避免生成多個EncryptFacade對象，節約系統資源。
4 結束語
外觀模式是一種使用頻率非常高的設計模式，在軟件開發中應用廣泛。針對標準外觀模式存在的不足，本文提出了兩種外觀模式的改進方案：第一種方案通過引入抽象外觀類，使得系統在增加、刪除或者更換子系統類時無須修改已有類的源代碼，可以對抽象外觀類進行擴展來適應設計方案的改變，讓系統滿足開閉原則;第二種方案通過對外觀類單例化，將外觀模式與單例模式聯用，確保在系統中只存在外觀類的唯一實例，節約系統資源。通過上述改進，可以提高外觀模式的適用性和有效性。
【基于軟件開發下外觀模式的改進研究論文】相關文章：
8.基于Watterson模型的相關信道下Goldencode性能研究論文
本文來源：http://www.nvnqwx.com/shiyongwen/2161003.htm