「每天一個知識點」精講設計模式之外觀模式

點擊上方"java全棧技術"關注，每天學習一個java知識點

外觀模式是一種使用頻率非常高的結構型設計模式，它通過引入一個外觀角色來簡化客戶端與子系統之間的交互，為複雜的子系統調用提供一個統一的入口，降低子系統與客戶端的耦合度，且客戶端調用非常方便。

1. 外觀模式概述

不知道大家有沒有比較過自己泡茶和去茶館喝茶的區別，如果是自己泡茶需要自行準備茶葉、茶具和開水，如圖1(A)所示，而去茶館喝茶，最簡單的方式就是跟茶館服務員說想要一杯什麼樣的茶，是鐵觀音、碧螺春還是西湖龍井？正因為茶館有服務員，顧客無須直接和茶葉、茶具、開水等交互，整個泡茶過程由服務員來完成，顧客只需與服務員交互即可，整個過程非常簡單省事，如圖1(B)所示。

圖1 兩種喝茶方式示意圖

在軟件開發中，有時候為了完成一項較為複雜的功能，一個客戶類需要和多個業務類交互，而這些需要交互的業務類經常會作為一個整體出現，由於涉及到的類比較多，導致使用時代碼較為複雜，此時，特別需要一個類似服務員一樣的角色，由它來負責和多個業務類進行交互，而客戶類只需與該類交互。外觀模式通過引入一個新的外觀類(Facade)來實現該功能，外觀類充當了軟件系統中的“服務員”，它為多個業務類的調用提供了一個統一的入口，簡化了類與類之間的交互。在外觀模式中，那些需要交互的業務類被稱為子系統(Subsystem)。如果沒有外觀類，那麼每個客戶類需要和多個子系統之間進行復雜的交互，系統的耦合度將很大，如圖2(A)所示；而引入外觀類之後，客戶類只需要直接與外觀類交互，客戶類與子系統之間原有的複雜引用關係由外觀類來實現，從而降低了系統的耦合度，如圖2(B)所示。

圖2 外觀模式示意圖

外觀模式中，一個子系統的外部與其內部的通信通過一個統一的外觀類進行，外觀類將客戶類與子系統的內部複雜性分隔開，使得客戶類只需要與外觀角色打交道，而不需要與子系統內部的很多對象打交道。

外觀模式定義如下：

外觀模式：為子系統中的一組接口提供一個統一的入口。外觀模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。

Facade Pattern: Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

外觀模式又稱為門面模式，它是一種對象結構型模式。外觀模式是迪米特法則的一種具體實現，通過引入一個新的外觀角色可以降低原有系統的複雜度，同時降低客戶類與子系統的耦合度。

2. 外觀模式結構與實現

2.1 模式結構

外觀模式沒有一個一般化的類圖描述，通常使用如圖2(B)所示示意圖來表示外觀模式。圖3所示的類圖也可以作為描述外觀模式的結構圖：

圖3 外觀模式結構圖

由圖3可知，外觀模式包含如下兩個角色：

(1) Facade（外觀角色）：

(2) SubSystem（子系統角色）：在軟件系統中可以有一個或者多個子系統角色，每一個子系統可以不是一個單獨的類，而是一個類的集合，它實現子系統的功能；每一個子系統都可以被客戶端直接調用，或者被外觀角色調用，它處理由外觀類傳過來的請求；子系統並不知道外觀的存在，對於子系統而言，外觀角色僅僅是另外一個客戶端而已。

2.2 模式實現

外觀模式的主要目的在於降低系統的複雜程度，在面向對象軟件系統中，類與類之間的關係越多，不能表示系統設計得越好，反而表示系統中類之間的耦合度太大，這樣的系統在維護和修改時都缺乏靈活性，因為一個類的改動會導致多個類發生變化，而外觀模式的引入在很大程度上降低了類與類之間的耦合關係。引入外觀模式之後，增加新的子系統或者移除子系統都非常方便，客戶類無須進行修改（或者極少的修改），只需要在外觀類中增加或移除對子系統的引用即可。從這一點來說，外觀模式在一定程度上並不符合開閉原則，增加新的子系統需要對原有系統進行一定的修改，雖然這個修改工作量不大。

外觀模式中所指的子系統是一個廣義的概念，它可以是一個類、一個功能模塊、系統的一個組成部分或者一個完整的系統。子系統類通常是一些業務類，實現了一些具體的、獨立的業務功能，其典型代碼如下：

在引入外觀類之後，與子系統業務類之間的交互統一由外觀類來完成，在外觀類中通常存在如下代碼：

由於在外觀類中維持了對子系統對象的引用，客戶端可以通過外觀類來間接調用子系統對象的業務方法，而無須與子系統對象直接交互。引入外觀類後，客戶端代碼變得非常簡單，典型代碼如下：

3. 外觀模式應用實例

下面通過一個應用實例來進一步學習和理解外觀模式。

1. 實例說明

某軟件公司欲開發一個可應用於多個軟件的文件加密模塊，該模塊可以對文件中的數據進行加密並將加密之後的數據存儲在一個新文件中，具體的流程包括三個部分，分別是讀取源文件、加密、保存加密之後的文件，其中，讀取文件和保存文件使用流來實現，加密操作通過求模運算實現。這三個操作相對獨立，為了實現代碼的獨立重用，讓設計更符合單一職責原則，這三個操作的業務代碼封裝在三個不同的類中。

現使用外觀模式設計該文件加密模塊。

2. 實例類圖

通過分析，本實例結構圖如圖4所示。

圖4 文件加密模塊結構圖

在圖4中，EncryptFacade充當外觀類，FileReader、CipherMachine和FileWriter充當子系統類。

3. 實例代碼

(1) FileReader：文件讀取類，充當子系統類。

(2) CipherMachine：數據加密類，充當子系統類。

(3) FileWriter：文件保存類，充當子系統類。

(4) EncryptFacade：加密外觀類，充當外觀類。

(5) Program：客戶端測試類

4. 結果及分析

編譯並運行程序，輸出結果如下：

讀取文件，獲取明文：Hello world!

數據加密，將明文轉換為密文：233364062325

保存密文，寫入文件。

在本實例中，對文件src.txt中的數據進行加密，該文件內容為“Hello world!”，加密之後將密文保存到另一個文件des.txt中，程序運行後保存在文件中的密文為“233364062325”。在加密類CipherMachine中，採用求模運算對明文進行加密，將明文中的每一個字符除以一個整數（本例中為7，可以由用戶來進行設置）後取餘數作為密文。

4. 抽象外觀類

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

下面通過一個具體實例來學習如何使用抽象外觀類：

如果在應用實例“文件加密模塊”中需要更換一個加密類，不再使用原有的基於求模運算的加密類CipherMachine，而改為基於移位運算的新加密類NewCipherMachine，其代碼如下：

如果不增加新的外觀類，只能通過修改原有外觀類EncryptFacade的源代碼來實現加密類的更換，將原有的對CipherMachine類型對象的引用改為對NewCipherMachine類型對象的引用，這違背了開閉原則，因此需要通過增加新的外觀類來實現對子系統對象引用的改變。

如果增加一個新的外觀類NewEncryptFacade來與FileReader類、FileWriter類以及新增加的NewCipherMachine類進行交互，雖然原有系統類庫無須做任何修改，但是因為客戶端代碼中原來針對EncryptFacade類進行編程，現在需要改為NewEncryptFacade類，因此需要修改客戶端源代碼。

如何在不修改客戶端代碼的前提下使用新的外觀類呢？解決方法之一是：引入一個抽象外觀類，客戶端針對抽象外觀類編程，而在運行時再確定具體外觀類，引入抽象外觀類之後的文件加密模塊結構圖如圖5所示：

圖5 引入抽象外觀類之後的文件加密模塊結構圖

在圖5中，客戶類Client針對抽象外觀類AbstractEncryptFacade進行編程，AbstractEncryptFacade代碼如下：

新增具體加密外觀類NewEncryptFacade代碼如下：

配置文件App.config中存儲了具體外觀類的類名，代碼如下：

客戶端測試代碼修改如下：

編譯並運行程序，輸出結果如下：讀取文件，獲取明文：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) 在層次化結構中，可以使用外觀模式定義系統中每一層的入口，層與層之間不直接產生聯繫，而通過外觀類建立聯繫，降低層之間的耦合度。

原文：http://blog.csdn.net/lovelion

閱讀更多 java全棧技術 的文章

關鍵字: 軟件 設計模式 客戶端