深入淺出外觀模式（一）

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

 

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 模式實現

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

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

class SubSystemA
{
    public void MethodA()
    {
        //業務實現程式碼
    }
}

class SubSystemB
{
    public void MethodB()
    {
        //業務實現程式碼
     }
}

class SubSystemC
{
    public void MethodC()
    {
        //業務實現程式碼
    }
}

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

class Facade
{
    private SubSystemA obj1 = new SubSystemA();
    private SubSystemB obj2 = new SubSystemB();
    private SubSystemC obj3 = new SubSystemC();

    public void Method()
    {
        obj1.MethodA();
        obj2.MethodB();
        obj3.MethodC();
    }
}

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

class Program
{
    static void Main(string[] args)
    {
        Facade facade = new Facade();
        facade.Method();
    }
}

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