定義

外觀模式(Facade Pattern)：外部與一個子系統的通信必須通過一個統一的外觀對象進行，為子系統中的一組接口提供一個一致的界面，外觀模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。外觀模式又稱為門面模式，它是一種對象結構型模式。

使用場景

當你要為一個復雜子系統提供一個簡單接口時。 客戶程序與抽象類的實現部分之間存在著很大的依賴性。引入Facade將這個子系統與客戶以及其他的子系統分離，可以提高子系統的獨立性和可移植性。 當你需要構建一個層次結構的子系統時，使用Facade模式定義子系統中每層的入口點，如果子系統之間是相互依賴的，你可以讓他們僅通過Facade進行通訊，從而簡化了他們之間的依賴關系。

結構

模式所涉及的角色有：

Client : 客戶端程序。

Facade : 對外的統一入口,即外觀對象。

SubSystem : 子系統或者子服務等等。

實現

編程嘛，抽象於生活高於生活，接下來我們用生活中智能家居的小例子來分析一下外觀模式。智能家居為什麼會流行，其中一個原因肯定是方便，我們用一個中央處理器就可以管理我們所有的智能家居產品，類似的還有現在的一站式服務。那麼用戶就是Client角色，中央處理器就是Facade角色，音箱、TV、空調等等就是SubSystem角色。

Facade角色

public class Facade {

    private Light mLight = new Light();
    private AirCondition mAirCondition = new AirCondition();

    /**
     * 還可能會有方法集，比如我的習慣是下班回家，開燈、開空調，空調溫度調節到20度
     */
    public void doMyHabit(){
        mLight.lightOn();
        mAirCondition.airConditionaOn();
        mAirCondition.setTemperature(20);
    }

    public void lightOn(){
        mLight.lightOn();
    }

    public void lightOff(){
        mLight.lightOff();
    }

    public void airConditionaOn() {
        mAirCondition.airConditionaOn();
    }

    public void airConditionaOff() {
        mAirCondition.airConditionaOff();
    }

    public void setTemperature(int temperature) {
        mAirCondition.setTemperature(temperature);
    }
}

子系統

public class Light {

    public void lightOn(){
        Log.e("Light","on");
    }

    public void lightOff(){
        Log.e("Light","off");
    }
}

public class AirCondition {

    public void airConditionaOn() {
        Log.e("AirCondition", "on");
    }

    public void airConditionaOff() {
        Log.e("AirCondition", "off");
    }

    public void setTemperature(int temperature) {
        Log.e("AirCondition", "temperature:" + temperature);
    }
}

不知道大家有沒有發現一個問題，外觀模式和我們上篇說的適配器模式是不是有一些相似呢？

Facade與Adapter和Proxy有類似之處，但是Proxy注重在為Client-Subject提供一個訪問的中間層，Adapter注重對接口的轉換與調整，而Facade所面對的往往是多個類或其他程序單元，通過重新組合各類及程序單元，對外提供統一的接口/界面。

Android源碼中的外觀模式

在Android中，Context類族是比較重要的，關於這些，在從裝飾者模式到Context類族,Android Handler 消息機制（解惑篇）中已經做過說明，這裡就不再畫UML圖了。

它是提供應用環境（application environment）信息的接口。通過它可以訪問到應用的資源和類，以及進行一些系統級別的操作，比如加載activity、發送廣播和接收intent等。這代表什麼呢，Context類給我們提供了一站式服務，這裡當然應用了外觀模式。

在應用啟動時，首先會fork一個子進程，並且調用ActivityThread.main方法啟動該進程。ActivityThread又會構建Application對象，然後和Activity、ContextImpl關聯起來，然後再調用Activity的onCreate、onStart、onResume函數使Activity運行起來。

Activity啟動之後，Android給我們提供了操作系統服務的統一入口，也就是Activity本身。這些工作並不是Activity自己實現的，而是將操作委托給Activity父類ContextThemeWrapper的mBase對象，這個對象的實現類就是ContextImpl ( 也就是performLaunchActivity方法中構建的ContextImpl )。

ContextImpl內部封裝了一些系統級別的操作，有的子系統功能雖然沒有實現，但是也提供了訪問該子系統的接口，比如獲取ActivityManager的getActivityManager方法。

外觀模式非常的簡單，只是封裝了子系統的操作，並且暴露接口讓用戶使用，避免了用戶需要與多個子系統進行交互，降低了系統的耦合度、復雜度。

測試代碼已上傳到github。

參考鏈接

https://github.com/simple-android-framework/android_design_patterns_analysis/tree/master/facade/elsdnwn