目錄

本文的結構如下：

• 什麼是外觀模式
• 模式的結構
• 程式碼示例
• 優點和缺點
• 適用環境
• 模式應用
• 模式擴充套件
• 補充

一、前言

話說某天空氣質量回到秦漢，月色如水傾瀉，溫度適宜，微風襲人，我在院子樹下架起圓木桌，擺上雕花凳，桌上依次擺放紅燒肘子，燒牛肉，剁椒魚頭，烤羊排，炸猛男……美人在懷，飲一口小酒，復又夾起一塊牛肉放入口中，這滋味，豈不快哉？

快你個頭啊，趕緊起來給我碼程式碼。

恍惚中聽到一聲怒吼，我從好夢中驚醒。啊，沒有酒，沒有肉，沒有美人，只有漢城4點鐘的太陽，油膩的中年組長大叔和螢幕前沒有吃完的老壇酸菜面，淚哭。

咳咳，回到正題，我們接著講美食。美食適合享用，不宜動手操弄，如果自己動手，要做好一道美食，需要的事物很多，碗，鍋，水，調味品，食材等等，需要這些東西經過一些列互動才能得到最後的美食。

美食做法實在太過累人，可是還是想吃怎麼辦呢？

找媽媽啊，一句：“媽，我想吃肉。”然後可以逛知乎，刷微博，打遊戲，在手機上進行了一輪複雜操作，就聽媽媽喊一聲：“吃飯了。”於是乎，一隻手握著手機改看小說，一隻手夾肉，嘴裡嘟囔道：“媽，你做的紅燒肉太好吃了。”

咳咳，這次真的回到正題。

剛才“餓了找媽媽”的例子其實就是在說外觀模式。在軟體開發中，有時候某個客戶類（“我”）可能會與多個業務類（“水，調味品，食材”）互動，而這些需要互動的業務類經常會作為一個整體出現，由於涉及到的類比較多，導致使用時程式碼較為複雜，此時，特別需要一個類似“媽媽”一樣的角色，由它來負責和多個業務類進行互動，而客戶類只需與該類互動。外觀模式通過引入一個新的外觀類(Facade)

來實現該功能，外觀類充當了軟體系統中的“媽媽”，它為多個業務類的呼叫提供了一個統一的入口，簡化了類與類之間的互動。在外觀模式中，那些需要互動的業務類被稱為子系統(Subsystem)。如果沒有外觀類，那麼每個客戶類需要和多個子系統之間進行復雜的互動，系統的耦合度將很大，而引入外觀類之後，客戶類只需要直接與外觀類互動，客戶類與子系統之間原有的複雜引用關係由外觀類來實現，從而降低了系統的耦合度。

插一句，不得不說，媽媽其實就像個服務員，不停服務自己的丈夫和孩子，還經常受到埋怨，太辛苦了。

二、什麼是外觀模式

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

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

三、模式的結構

外觀模式包含如下兩個角色：

• Facade（外觀角色）：在客戶端可以呼叫它的方法，在外觀角色中可以知道相關的（一個或者多個）子系統的功能和責任；在正常情況下，它將所有從客戶端發來的請求委派到相應的子系統去，傳遞給相應的子系統物件處理。
• SubSystem（子系統角色）：在軟體系統中可以有一個或者多個子系統角色，每一個子系統可以不是一個單獨的類，而是一個類的集合，它實現子系統的功能；每一個子系統都可以被客戶端直接呼叫，或者被外觀角色呼叫，它處理由外觀類傳過來的請求；子系統並不知道外觀的存在，對於子系統而言，外觀角色僅僅是另外一個客戶端而已。

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

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();
    }
}

四、程式碼示例

4.1、就以“餓了找媽媽”為例，在不使用外觀模式前，是這樣設計的：

/**
 * Created by w1992wishes on 2017/11/9.
 */
public class Material {
    public void prepare(){
        System.out.println("從菜市場買回食材，並清洗");
    }
}

/**
 * Created by w1992wishes on 2017/11/9.
 */
public class Pan {
    public void wash(){
        System.out.println("炒菜前要先洗鍋");
    }
}

/**
 * Created by w1992wishes on 2017/11/9.
 */
public class Flavouring {
    public void add(){
        System.out.println("依次放入各種調味品");
    }
}

我進行製作美食：

/**
 * Created by w1992wishes on 2017/11/9.
 */
public class Client {
    public static void main(String[] args) {
        Material material = new Material();
        Pan pan = new Pan();
        Flavouring flavouring = new Flavouring();

        System.out.println("肚子餓了");
        material.prepare();
        pan.wash();
        flavouring.add();
        System.out.println("出鍋，可以吃飯了");
    }
}

結果： 肚子餓了 從菜市場買回食材，並清洗 炒菜前要先洗鍋 依次放入各種調味品 出鍋，可以吃飯了

4.2、使用外觀模式

/**
 * Created by w1992wishes on 2017/11/9.
 */
public class Mom {
    Material material;
    Pan pan;
    Flavouring flavouring;
    public Mom(){
        this.material = new Material();
        this.pan = pan = new Pan();
        this.flavouring = new Flavouring();
    }
    public void makeDish(){
        material.prepare();
        pan.wash();
        flavouring.add();
    }
}

媽媽製作美食：

public class Client {
    public static void main(String[] args) {
        Mom mom = new Mom();

        System.out.println("肚子餓了");
        mom.makeDish();
        System.out.println("出鍋，可以吃飯了");
    }
}

五、優點和缺點

5.1、優點

• 對客戶遮蔽子系統元件，減少了客戶處理的物件數目並使得子系統使用起來更加容易。通過引入外觀模式，客戶程式碼將變得很簡單，與之關聯的物件也很少。
• 實現了子系統與客戶之間的鬆耦合關係，這使得子系統的元件變化不會影響到呼叫它的客戶類，只需要調整外觀類即可。
• 降低了大型軟體系統中的編譯依賴性，並簡化了系統在不同平臺之間的移植過程，因為編譯一個子系統一般不需要編譯所有其他的子系統。一個子系統的修改對其他子系統沒有任何影響，而且子系統內部變化也不會影響到外觀物件。
• 只是提供了一個訪問子系統的統一入口，並不影響使用者直接使用子系統類。

5.2、缺點

• 不能很好地限制客戶使用子系統類，如果對客戶訪問子系統類做太多的限制則減少了可變性和靈活性。
• 在不引入抽象外觀類的情況下，增加新的子系統可能需要修改外觀類或客戶端的原始碼，違背了“開閉原則”。

六、適用環境

在以下情況下可以使用外觀模式：

• 當要為一個複雜子系統提供一個簡單介面時可以使用外觀模式。該介面可以滿足大多數使用者的需求，而且使用者也可以越過外觀類直接訪問子系統。
• 客戶程式與多個子系統之間存在很大的依賴性。引入外觀類將子系統與客戶以及其他子系統解耦，可以提高子系統的獨立性和可移植性。
• 在層次化結構中，可以使用外觀模式定義系統中每一層的入口，層與層之間不直接產生聯絡，而通過外觀類建立聯絡，降低層之間的耦合度。

七、模式應用

八、模式擴充套件

• 一個系統可以有多個外觀類：在外觀模式中，通常只需要一個外觀類，並且此外觀類只有一個例項，換言之它是一個單例類。在很多情況下為了節約系統資源，一般將外觀類設計為單例類。當然這並不意味著在整個系統裡只能有一個外觀類，在一個系統中可以設計多個外觀類，每個外觀類都負責和一些特定的子系統互動，向用戶提供相應的業務功能。
• 不要試圖通過外觀類為子系統增加新行為：不要通過繼承一個外觀類在子系統中加入新的行為，這種做法是錯誤的。外觀模式的用意是為子系統提供一個集中化和簡化的溝通渠道，而不是向子系統加入新的行為，新的行為的增加應該通過修改原有子系統類或增加新的子系統類來實現，不能通過外觀類來實現。
• 外觀模式與迪米特法則：外觀模式創造出一個外觀物件，將客戶端所涉及的屬於一個子系統的協作夥伴的數量減到最少，使得客戶端與子系統內部的物件的相互作用被外觀物件所取代。外觀類充當了客戶類與子系統類之間的“第三者”，降低了客戶類與子系統類之間的耦合度，外觀模式就是實現程式碼重構以便達到“迪米特法則”要求的一個強有力的武器。
• 抽象外觀類的引入：在標準的外觀模式結構圖中，如果需要增加、刪除或更換與外觀類互動的子系統類，必須修改外觀類或客戶端的原始碼，這將違背開閉原則，因此可以通過引入抽象外觀類來對系統進行改進，在一定程度上可以解決該問題。在引入抽象外觀類之後，客戶端可以針對抽象外觀類進行程式設計，對於新的業務需求，不需要修改原有外觀類，而對應增加一個新的具體外觀類，由新的具體外觀類來關聯新的子系統物件，同時通過修改配置檔案來達到不修改任何原始碼並更換外觀類的目的。

九、補充–與介面卡模式的區別

• 外觀模式的實現核心主要是——由外觀類去儲存各個子系統的引用，實現由一個統一的外觀類去包裝多個子系統類，然後客戶端只需要引用這個外觀類，然後由外觀類來呼叫各個子系統中的方法。
• 這樣的實現方式非常類似介面卡模式，然而外觀模式與介面卡模式不同的是：介面卡模式是將一個物件包裝起來以改變其介面，而外觀是將一群物件 ”包裝“起來以簡化其介面。它們的意圖是不一樣的，介面卡是將介面轉換為不同介面，而外觀模式是提供一個統一的介面來簡化介面。

--------------------- 本文來自 w1992wishes 的CSDN 部落格 ，全文地址請點選：https://blog.csdn.net/w1992wishes/article/details/78491346?utm_source=copy