# 深入淺出外觀模式（三） 4. 抽象外觀類 在標準的外觀模式結構圖中，如果需要增加、刪除或更換與外觀類交互的子系統類，必須修改外觀類或客戶端的源代碼，這將違背開閉原則，因此可以通過引入抽象外觀類來對系統進行改進，在一定程度上可以解決該問題。在引入抽象外觀類之后，客戶端可以針對抽象外觀類進行編程，對于新的業務需求，不需要修改原有外觀類，而對應增加一個新的具體外觀類，由新的具體外觀類來關聯新的子系統對象，同時通過修改配置文件來達到不修改任何源代碼并更換外觀類的目的。 下面通過一個具體實例來學習如何使用抽象外觀類： 如果在應用實例“文件加密模塊”中需要更換一個加密類，不再使用原有的基于求模運算的加密類CipherMachine，而改為基于移位運算的新加密類NewCipherMachine，其代碼如下： ``` using System; namespace FacadeSample { class NewCipherMachine { public string Encrypt(string plainText) { Console.Write("數據加密，將明文轉換為密文："); string es = ""; int key = 10;//設置密鑰，移位數為10 char[] chars = plainText.ToCharArray(); foreach(char ch in chars) { int temp = Convert.ToInt32(ch); //小寫字母移位 if (ch >= 'a' && ch <= 'z') { temp += key % 26; if (temp > 122) temp -= 26; if (temp < 97) temp += 26; } //大寫字母移位 if (ch >= 'A' && ch <= 'Z') { temp += key % 26; if (temp > 90) temp -= 26; if (temp < 65) temp += 26; } es += ((char)temp).ToString(); } Console.WriteLine(es); return es; } } } ``` 如果不增加新的外觀類，只能通過修改原有外觀類EncryptFacade的源代碼來實現加密類的更換，將原有的對CipherMachine類型對象的引用改為對NewCipherMachine類型對象的引用，這違背了開閉原則，因此需要通過增加新的外觀類來實現對子系統對象引用的改變。 如果增加一個新的外觀類NewEncryptFacade來與FileReader類、FileWriter類以及新增加的NewCipherMachine類進行交互，雖然原有系統類庫無須做任何修改，但是因為客戶端代碼中原來針對EncryptFacade類進行編程，現在需要改為NewEncryptFacade類，因此需要修改客戶端源代碼。 如何在不修改客戶端代碼的前提下使用新的外觀類呢？解決方法之一是：引入一個抽象外觀類，客戶端針對抽象外觀類編程，而在運行時再確定具體外觀類，引入抽象外觀類之后的文件加密模塊結構圖如圖5所示：  圖5 引入抽象外觀類之后的文件加密模塊結構圖 在圖5中，客戶類Client針對抽象外觀類AbstractEncryptFacade進行編程，AbstractEncryptFacade代碼如下： ``` namespace FacadeSample { abstract class AbstractEncryptFacade { public abstract void FileEncrypt(string fileNameSrc, string fileNameDes); } } 新增具體加密外觀類NewEncryptFacade代碼如下： [csharp] view plain copy namespace FacadeSample { class NewEncryptFacade : AbstractEncryptFacade { private FileReader reader; private NewCipherMachine cipher; private FileWriter writer; public NewEncryptFacade() { reader = new FileReader(); cipher = new NewCipherMachine(); writer = new FileWriter(); } public override void FileEncrypt(string fileNameSrc, string fileNameDes) { string plainStr = reader.Read(fileNameSrc); string encryptStr = cipher.Encrypt(plainStr); writer.Write(encryptStr, fileNameDes); } } } ``` 配置文件App.config中存儲了具體外觀類的類名，代碼如下： ``` <?xml version="1.0" encoding="utf-8" ?> <configuration> <appSettings> <add key="facade" value="FacadeSample.NewEncryptFacade"/> </appSettings> </configuration> ``` 客戶端測試代碼修改如下： ``` using System; using System.Configuration; using System.Reflection; namespace FacadeSample { class Program { static void Main(string[] args) { AbstractEncryptFacade ef; //針對抽象外觀類編程 //讀取配置文件 string facadeString = ConfigurationManager.AppSettings["facade"]; //反射生成對象 ef = (AbstractEncryptFacade)Assembly.Load("FacadeSample"). CreateInstance (facadeString); ef.FileEncrypt("src.txt", "des.txt"); Console.Read(); } } } ``` 編譯并運行程序，輸出結果如下： ``` 讀取文件，獲取明文：Hello world! 數據加密，將明文轉換為密文：Rovvy gybvn! 保存密文，寫入文件。 ``` 原有外觀類EncryptFacade也需作為抽象外觀類AbstractEncryptFacade類的子類，更換具體外觀類時只需修改配置文件，無須修改源代碼，符合開閉原則。 5. 外觀模式效果與適用場景 外觀模式是一種使用頻率非常高的設計模式，它通過引入一個外觀角色來簡化客戶端與子系統之間的交互，為復雜的子系統調用提供一個統一的入口，使子系統與客戶端的耦合度降低，且客戶端調用非常方便。外觀模式并不給系統增加任何新功能，它僅僅是簡化調用接口。在幾乎所有的軟件中都能夠找到外觀模式的應用，如絕大多數B/S系統都有一個首頁或者導航頁面，大部分C/S系統都提供了菜單或者工具欄，在這里，首頁和導航頁面就是B/S系統的外觀角色，而菜單和工具欄就是C/S系統的外觀角色，通過它們用戶可以快速訪問子系統，降低了系統的復雜程度。所有涉及到與多個業務對象交互的場景都可以考慮使用外觀模式進行重構。 5.1 模式優點 外觀模式的主要優點如下： (1) 它對客戶端屏蔽了子系統組件，減少了客戶端所需處理的對象數目，并使得子系統使用起來更加容易。通過引入外觀模式，客戶端代碼將變得很簡單，與之關聯的對象也很少。 (2) 它實現了子系統與客戶端之間的松耦合關系，這使得子系統的變化不會影響到調用它的客戶端，只需要調整外觀類即可。 (3) 一個子系統的修改對其他子系統沒有任何影響，而且子系統內部變化也不會影響到外觀對象。 5.2 模式缺點 外觀模式的主要缺點如下： (1) 不能很好地限制客戶端直接使用子系統類，如果對客戶端訪問子系統類做太多的限制則減少了可變性和靈活 性。 (2) 如果設計不當，增加新的子系統可能需要修改外觀類的源代碼，違背了開閉原則。 5.3 模式適用場景 在以下情況下可以考慮使用外觀模式： (1) 當要為訪問一系列復雜的子系統提供一個簡單入口時可以使用外觀模式。 (2) 客戶端程序與多個子系統之間存在很大的依賴性。引入外觀類可以將子系統與客戶端解耦，從而提高子系統的獨立性和可移植性。 (3) 在層次化結構中，可以使用外觀模式定義系統中每一層的入口，層與層之間不直接產生聯系，而通過外觀類建立聯系，降低層之間的耦合度。