外觀模式門面模式 Facade 結構型設計模式（十三）

外觀模式又稱為門面模式Facade是一種簡單的設計模式，但是他背後的思想為迪米特原則，理解門面模式更有助於理解迪米特原則--不要和陌生人說話的原則，可以降低系統的耦合程度，本文介紹了外觀模式的意圖，結構，並且給出了java代碼示例。 ...

外觀模式（FACADE）又稱為門面模式

意圖

為子系統中的一組介面提供一個一致的界面 Facade模式定義了一個高層介面，這一介面使得這一子系統更加易於使用。

意圖解析

隨著項目的持續發展，系統基本上都是會往功能更全面的方向發展，那麼也就意味著我們的系統將會變得更加複雜。系統會被劃分為多個單獨的子系統，每個子系統完成一部分功能，通過分工協作完成全部功能。一個子系統也可能進一步拆分為更小的幾個子系統。程式中的文件將會越來越多，相互關聯也會變得更加複雜當使用一個功能的時候，作為客戶端你需要弄清楚相關類之間的關係，以及正確的調用順序。比如下圖中你需要自己識別有哪些子系統，涉及哪些相關的類和方法，你需要自己保證順序（如果功能調用依賴順序的話）

如同在醫院裡面，病人需要自己去排隊掛號化驗，跟每個流程的工作人員進行協作如同在工廠裡面，需要生產一個桌子，你親自用機器生產桌子腿，自己使用機器生產桌面... 如同你去其他公司洽談業務，你單獨跟每個相關業務的人員進行聯繫溝通你肯定想得到，如果有一個中間人為你代勞不需要面對林林總總的子系統、部門、人員... 當你需要某種服務時，只需要告訴這個中間人就好了這個想法就是外觀模式

有了facade，你就不需要跟每個子系統進行單獨的交流了 如同在醫院裡面，對於VIP，有專人代替你掛號..... 如同在工廠裡面，有一個控制台機器，你選擇產品，控制臺下發命令安排其他的機器生產具體產品如同你去其他公司洽談業務，有一個介面人負責與你對接，他們那邊的事情都通過這個人進行安排

外觀模式的意圖含義，如同他的名字一樣，“建築物的正面” 面對一個複雜的大樓，當你在正面遠遠望去，也就只能看到正面 在外觀模式中，形容一個龐大的複雜的系統的一個直觀的界面 藉助於Facade模式 從原來的“客戶端需要跟多個子系統進行交互”，轉變為“只與Facade進行交互” 將客戶端與子系統進行解耦，降低了耦合性，也降低了使用的複雜度

代碼示例

“關好門窗，防火防盜”這句話有沒有聽過？回想一下，當你早上準備出門離開家時，你會做什麼？假設你會關水、關燈、關門窗。我們創建三個類，水燈窗，模擬離開家的場景

package facade;
public class Water {
public void turnOn() {
        System.out.println("打開水龍頭...");
    }   
    public void turnOff() {
        System.out.println("關閉水龍頭...");
    }
}

package facade;
public class Light {
    public void turnOn() {
        System.out.println("開燈...");
    } 
    public void turnOff() {
        System.out.println("關燈...");
    }
}

package facade;
 
public class Window {
    public void open() {
        System.out.println("開窗...");
    } 
    public void close() {
        System.out.println("關窗...");
    }
}

測試代碼

上面的測試代碼Test作為客戶端程式，可以看得出來，他直接跟Water Light Window三個類的對象進行交互他需要調用相關的方法也就是說Test 作為客戶端對於“離家”這一系統的內部邏輯是瞭如指掌的--->需要斷水、關燈、關窗他也清楚每個類的方法一方面增加了耦合性，另一方面將子系統的內部細節暴露出來

優化重構

試想下，如果你家是智能家居，有一個控制台Facade，或者說有一個手機App 他可以控制整個家庭的設備

package facade;
 
public class Facade {
    private Water water = new Water();
    private Light light = new Light();
    private Window window = new Window();
    
    public void leaveHome(){
        water.turnOff();
        light.turnOff();
        window.close();
    }
     
    public void backHome(){
        light.turnOn();
        window.open();
    }
 
}

通過這個控制台，客戶端程式不再需要瞭解子系統的內部細節，他也不清楚每個類到底有哪些方法所有的交互都是通過Facade來完成的

結構

Facade 外觀角色 客戶端調用角色，知曉子系統的所有功能與職責通常，Facade會將所有的請求轉發委派到子系統中去，也就是說該角色沒有實際的業務、 SubSystem子系統角色 可以同時有一個或者多個子系統註意 :子系統並不是說一個單獨的類，而是一個類的集合，這些類根據邏輯功能點被組織在一起 子系統並不知道Facade的存在，對於子系統來說，Facade也就只是一個客戶端程式 外觀模式的結構比較簡單，類似一個“封裝”提取的過程他的根本原則為迪米特法則，也就是“不要和陌生人說話”，儘可能少的與其他的對象進行交互通過外觀模式，做到了子系統只與外觀對象交互 門面類個數 在門面模式中，通常只需要一個門面類，並且這個門面類只有一個實例換句話說他很可能是一個單例但是並不是說整個系統中只能有一個門面類門面類的個數要根據系統中子系統的個數以及業務邏輯的情況

總結

當你需要為一個複雜的子系統提供一個簡單的介面時或者希望子系統能夠更加獨立時，可以考慮使用外觀模式 藉助於外觀模式，可以實現客戶端與子系統的解耦，減少客戶端對子系統的依賴性 一旦完成解耦，就意味著子系統有良好的獨立性，也能擁有更好的擴展性因為獨立了，就意味著單獨的子系統修改不會影響其他系統而且，在多層次結構的系統中，可以使用Facade模式進行層與層之間的交互，將層與層之間的耦合性降低，使他們僅僅通過facade進行交互 總之一句話，降低了使用子系統的複雜程度，降低了耦合程度，滿足迪米特法則----不要和陌生人說話對客戶端屏蔽了子系統的組件僅僅通過Facade，大大減少了客戶端所需要處理的對象的數目 對於外觀模式，如果是子系統發生變化，Facade則極有可能需要面臨修改，這不符合開閉原則 外觀模式（門面模式）就如同我們開篇的圖片一樣，作為公司前臺接待來訪賓客，一切事宜都有她來協調安排組織。在OOP中，這個“前臺”不僅是一個子系統的“正面”看到的樣子，而且還強調了她的全權負責她提供所有的業務需要的相關方法，儘管內部調用都是子系統中的方法，她提供簡單一致的交流溝通形式理解了迪米特法則，那麼就比較容易理解外觀模式 外觀模式重點在於提供一個“簡化”“封裝”後的操作控制台，讓你更容易操作整個系統，他幾乎不會涉及子系統的內部邏輯 否則，門面對象將與子系統的業務邏輯耦合，增加了耦合度。 原文地址:外觀模式門面模式 Facade 創建型設計模式（十三）

外觀模式 門面模式 Facade 結構型 設計模式（十三）

意圖

意圖解析

代碼示例

優化重構

結構

總結

外觀模式門面模式 Facade 結構型設計模式（十三）