c 設計模式之外觀模式（Facade）

一、引言

在軟體開發過程中，客戶端程式經常會與複雜系統的內部子系統進行耦合，從而導致客戶端程式隨著子系統的變化而變化，然而為了將複雜系統的內部子系統與客戶端之間的依賴解耦，從而就有了外觀模式，也稱作」門面「模式。下面就具體介紹下外觀模式。

二、外觀模式的詳細介紹

2.1定義

外觀模式提供了乙個統一的介面，用來訪問子系統中的一群介面。外觀定義了乙個高層介面，讓子系統更容易使用。使用外觀模式時，我們建立了乙個統一的類，用來包裝子系統中乙個或多個複雜的類，客戶端可以直接通過外觀類來呼叫內部子系統中方法，從而外觀模式讓客戶和子系統之間避免了緊耦合。

2.2 外觀模式的結構圖

介紹了外觀模式的定義之後，讓我們具體看看外觀模式的由來以及實現，下面與學校中乙個選課系統為例來解釋外觀模式，例如在選課系統中，有註冊課程子系統和通知子系統，在不使用外觀模式的情況下，客戶端必須同時儲存註冊課程子系統和通知子系統兩個引用，如果後期這兩個子系統發生改變時，此時客戶端的呼叫**也要隨之改變，這樣就沒有很好的可擴充套件性，下面看看不使用外觀模式下選課系統的實現方式和客戶端呼叫**：

/// 
/// 不使用外觀模式的情況
/// 此時客戶端與三個子系統都傳送了耦合，使得客戶端程式依賴與子系統
/// 為了解決這樣的問題，我們可以使用外觀模式來為所有子系統設計乙個統一的介面
/// 客戶端只需要呼叫外觀類中的方法就可以了，簡化了客戶端的操作
/// 從而讓客戶和子系統之間避免了緊耦合
/// 
class client
}// 子系統a
public
class subsystema
}// 子系統b
public
class subsystemb
}// 子系統c
public
class subsystemc
}

view code

然而外觀模式可以解決我們上面所說的問題，下面具體看看使用外觀模式的實現：

234
5678
91011/// 
/// 以學生選課系統為例子演示外觀模式的使用
/// 學生選課模組包括功能有：
/// 驗證選課的人數是否已滿
/// 通知使用者課程選擇成功與否
/// 客戶端**
/// 
class student
else
console.read();}}
// 外觀類
public
class registrationfacade
public
bool registercourse(string coursename, string studentname)
return notifystu.notify(studentname);}}
#region 子系統
// 相當於子系統a
public
class registercourse
是否人數已滿", coursename);
return
true;}}
// 相當於子系統b
public
class notifystudent
發生通知", studentname);
return
true;}}
#endregion

view code

使用了外觀模式之後，客戶端只依賴與外觀類，從而將客戶端與子系統的依賴解耦了，如果子系統發生改變，此時客戶端的**並不需要去改變。外觀模式的實現核心主要是——由外觀類去儲存各個子系統的引用，實現由乙個統一的外觀類去包裝多個子系統類，然而客戶端只需要引用這個外觀類，然後由外觀類來呼叫各個子系統中的方法。然而這樣的實現方式非常類似介面卡模式，然而外觀模式與介面卡模式不同的是：介面卡模式是將乙個物件包裝起來以改變其介面，而外觀是將一群物件」包裝「起來以簡化其介面。它們的意圖是不一樣的，介面卡是將介面轉換為不同介面，而外觀模式是提供乙個統一的介面來簡化介面。三、外觀的優缺點

3.1】、外觀模式的優點：

（1）、外觀模式對客戶遮蔽了子系統元件，從而簡化了介面，減少了客戶處理的物件數目並使子系統的使用更加簡單。

（2）、外觀模式實現了子系統與客戶之間的松耦合關係，而子系統內部的功能元件是緊耦合的。松耦合使得子系統的元件變化不會影響到它的客戶。

3.2】、外觀模式的缺點：

（1）、如果增加新的子系統可能需要修改外觀類或客戶端的源**，這樣就違背了」開——閉原則「（不過這點也是不可避免）。

3.3】、在以下情況下可以考慮使用外觀模式：

（1）、外乙個複雜的子系統提供乙個簡單的介面

（2）、提供子系統的獨立性

（3）、在層次化結構中，可以使用外觀模式定義系統中每一層的入口。其中三層架構就是這樣的乙個例子。

四、總結

facade設計模式更注重從架構的層次去看整個系統，而不是單個類的層次。facade很多時候更是一種架構設計模式。注意區分facade模式、adapter模式、bridge模式與decorator模式：

facade模式注重簡化介面

adapter模式注重轉換介面

bridge模式注重分離介面（抽象）與其實現

decorator模式注重穩定介面的前提下為物件擴充套件功能

c 設計模式之外觀模式（Facade）

c 設計模式之外觀模式

C 設計模式之外觀模式

C 設計模式之外觀

c 設計模式之 外觀模式（Facade）

c 設計模式之外觀模式

C 設計模式之外觀模式

C 設計模式之外觀

相關推薦

c 設計模式之外觀模式（Facade）