PS一句：最終還是選擇CSDN來整理髮表這幾年的知識點，該文章平行遷移到CSDN。因為CSDN也支援MarkDown語法了，牛逼啊！

概述

一個客戶類需要和多個業務類互動，而這些業務類經常會作為整體出現，由於涉及到的類比較多，導致使用時程式碼較為複雜。外觀模式通過引入一個新的外觀類(Facade)來實現該功能，外觀類為多個業務類的呼叫提供統一入口，簡化了類與類之間的互動。如果沒有外觀類，那麼每個客戶類需要和多個業務類之間進行復雜的互動，系統的耦合度將很大。外觀模式是迪米特法則的一種具體實現，通過引入一個新的外觀角色可以降低原有系統的複雜度，同時降低客戶類與子系統的耦合度。

核心

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

重點： 外觀模式結構重要核心模組：

外觀角色

客戶端可以呼叫它的方法，在外觀角色中可以知道相關子系統的功能和責任；在正常情況下，它將所有從客戶端發來的請求委派到相應的子系統去，傳遞給相應的子系統物件處理。

子系統角色

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

使用場景

需要訪問一系列複雜的子系統時提供一個簡單入口。

客戶端程式與多個子系統之間存在很大的依賴性。引入外觀類可以將子系統與客戶端解耦，從而提高子系統的獨立性和可移植性。

在層次化結構中，可以使用外觀模式定義系統中每一層的入口，層與層之間不直接產生聯絡，而通過外觀類建立聯絡，降低層之間的耦合度。

程式猿例項

這裡還是以苦逼的程式猿為例來說明外觀模式。一個Android開發者開發Android程式需要很多工具條件，電腦，軟體，網路。如下實現：

package yanbober.github.io;
//子系統角色
class Computer {
    public void
 
 thinkpad() {
        System.out.println("Computer is ThinkPad!");
    }
}

class EathNet {
    public void net() {
        System.out.println("Net is CMCC!");
    }
}

class DeveloperTools {
    public void tools() {
        System.out.println("Developer Tool is Android Studio!");
    }
}
//外觀角色
class AndroidDeveloperEquipment {
    public void equipment() {
        new Computer().thinkpad();
        new EathNet().net();
        new DeveloperTools().tools();
    }
}

public class Main {
    public static void main(String[] args) {
        AndroidDeveloperEquipment dev = new AndroidDeveloperEquipment();
        dev.equipment();
    }
}

總結一把

外觀模式優點：

• 減少客戶端所需處理的物件數目，使得子系統使用起來更加容易。
• 實現了子系統與客戶端之間的鬆耦合關係。
• 一個子系統的修改對其他子系統沒有任何影響，而且子系統內部變化也不會影響到外觀物件。

外觀模式缺點：

• 不能很好地限制客戶端直接使用子系統類，如果對客戶端訪問子系統類做太多的限制則減少了可變性和靈活性。
• 如果設計不當，增加新的子系統可能需要修改外觀類的原始碼，違背了開閉原則。