外觀模式及其改進（二）：抽象外觀類的引入

      在通用的外觀模式結構圖中，如果需要增加、刪除或更換與外觀類互動的子系統類，必須修改外觀類或客戶端的原始碼，這將違背開閉原則，因此我們可以通過引入抽象外觀類來對系統進行改進，在一定程度上解決該問題。在引入抽象外觀類之後，客戶端可以針對抽象外觀類進行程式設計，對於新的業務需求，不需要修改原有外觀類，而對應增加一個新的具體外觀類，由新的具體外觀類來關聯新的子系統物件，同時通過修改配置檔案來達到不修改任何原始碼並更換外觀類的目的。引入抽象外觀類的外觀模式結構如圖4所示：

圖4  引入抽象外觀類的外觀模式結構圖

      如果需要將圖3中的加密類CipherMachine改為另一個加密類，例如NewCipherMachine，勢必會導致外觀類EncryptFacade原始碼發生修改，違反開閉原則。通過引入抽象外觀類，重構後的系統設計方案如圖5所示：

圖5  引入抽象外觀類之後的檔案加密模組結構圖

      在圖5中，客戶類Client針對抽象外觀類AbstractEncryptFacade進行程式設計，可以將具體外觀類類名儲存在XML等格式的配置檔案中，如下程式碼所示：

<?xml version="1.0"?>
<config>
    <className>EncryptFacade</className>
</config>

      引入抽象外觀類之後，客戶類針對抽象外觀類程式設計，更換具體外觀類時只需修改配置檔案，無須修改原始碼，符合開閉原則。

【作者：劉偉  http://blog.csdn.net/lovelion】