基於軟體開發下外觀模式的改進研究論文

外觀模式是使用頻率較高的軟體設計模式之一。針對標準外觀模式所存在的問題，本文提出了兩種外觀模式改進方案並結合例項進行研究。通過引入抽象外觀類，讓系統具有良好的可擴充套件性，滿足開閉原則;通過對外觀類實施單例化，可以確保外觀物件的唯一性，節約系統資源。

1 引言

設計模式在軟體開發中應用日益廣泛，它們是前人經驗的總結與積累，每一種模式均是在多個軟體專案中被反覆使用、被多數人知曉，且經過規範的分類編目和整理的物件導向設計經驗的總結。

外觀模式是使用頻率較高的軟體設計模式之一，在軟體開發中應用非常廣泛。根據單一職責原則，將一個大的軟體模組(或子系統)進行分解可以降低整個系統的複雜性，提高單個模組(或子系統)的獨立性和可複用性。通過引入外觀角色，可以降低客戶類與子系統類之間的耦合度，使之相互依賴關係降至最小，從而降低原有系統的複雜度。在沒有外觀角色的系統中，客戶類需要與多個子系統類進行互動，系統耦合度較高;在引入外觀角色之後，客戶類只需要與外觀類互動，再通過外觀類間接呼叫子系統類，在外觀類中封裝了與子系統之間的複雜互動關係，從而降低系統的耦合度。

但是，在標準的外觀模式中存在兩個問題：首先，標準外觀模式沒有提供抽象層，在增加、更換或者刪除子系統類時需要修改客戶類或者外觀類的原始碼，違背了開閉原則;其次，外觀類維持了對多個子系統類的引用，在系統執行時，外觀物件勢必會佔用較多的系統資源，需要對外觀物件的數量進行限制。

2 外觀模式的改進方案

針對標準外觀模式存在的問題和缺陷，本文提出了相應的改進方案，包括引入抽象外觀類以及對外觀類實施單例化。

2.1 抽象外觀類的引入

為了讓外觀模式能夠符合開閉原則，引入抽象外觀類來對外觀模式進行抽象化改進。客戶端針對抽象外觀類進行程式設計，將所有的具體外觀類作為抽象外觀類的子類，如果需要更改業務需求，無須修改原有外觀類，只需要增加一個新的具體外觀類即可，由新的外觀類來關聯新的業務需求。通過使用配置檔案，可以達到不修改任何原始碼即可置換外觀類的目的，如圖1所示。

2.2 外觀類的單例化

在大多數情況下，為了節約系統資源，程式在執行時只需建立某個外觀類的唯一例項。因此，可以將外觀模式與單例模式聯用，對外觀類實施單例化，確保系統中只存在唯一一個外觀物件並提供唯一的訪問入口，可以降低系統資源的消耗。單例化後的外觀類的結構如圖2所示。

在圖2中，外觀類Facade被設計為單例類，在其中定義了一個靜態的de型別的成員變數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 結束語

外觀模式是一種使用頻率非常高的設計模式，在軟體開發中應用廣泛。針對標準外觀模式存在的不足，本文提出了兩種外觀模式的改進方案：第一種方案通過引入抽象外觀類，使得系統在增加、刪除或者更換子系統類時無須修改已有類的原始碼，可以對抽象外觀類進行擴充套件來適應設計方案的改變，讓系統滿足開閉原則;第二種方案通過對外觀類單例化，將外觀模式與單例模式聯用，確保在系統中只存在外觀類的唯一例項，節約系統資源。通過上述改進，可以提高外觀模式的適用性和有效性。