模式動機

引入外觀角色之后，用戶只需要直接與外觀角色交互，用戶與子系統之間的復雜關系由外觀角色來實現，從而降低了系統的耦合度。

模式定義

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

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

模式結構

角色

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

外觀模式的目的不是給予子系統添加新的功能接口，而是為了讓外部減少與子系統內多個模塊的交互，松散耦合，從而讓外部能夠更簡單地使用子系統。

外觀模式的本質是：封裝交互，簡化調用。

模式分析

根據“單一職責原則”，在軟件中將一個系統劃分為若干個子系統有利于降低整個系統的復雜性，一個常見的設計目標是使子系統間的通信和相互依賴關系達到最小，而達到該目標的途徑之一就是引入一個外觀對象，它為子系統的訪問提供了一個簡單而單一的入口。

外觀模式也是“迪米特法則”的體現，通過引入一個新的外觀類可以降低原有系統的復雜度，同時降低客戶類與子系統類的耦合度。

外觀模式要求一個子系統的外部與其內部的通信通過一個統一的外觀對象進行，外觀類將客戶端與子系統的內部復雜性分隔開，使得客戶端只需要與外觀對象打交道，而不需要與子系統內部的很多對象打交道。

外觀模式的目的在于降低系統的復雜程度。

外觀模式從很大程度上提高了客戶端使用的便捷性，使得客戶端無須關心子系統的工作細節，通過外觀角色即可調用相關功能。

典型的外觀角色代碼

 public class Facade
  {
      private SubSystemA obj1 = new SubSystemA();
      private SubSystemB obj2 = new SubSystemB();
      private SubSystemC obj3 = new SubSystemC();
      public void method()
      {
          obj1.method();
          obj2.method();
         obj3.method();
     }
 } 

外觀模式實例與解析

實例一：電源總開關

現在考察一個電源總開關的例子，以便進一步說明外觀模式。為了使用方便，一個電源總開關可以控制四盞燈、一個風扇、一臺空調和一臺電視機的啟動和關閉。通過該電源總開關可以同時控制上述所有電器設備，使用外觀模式設計該系統

//子系統角色
public class Fan 
{
    private Fan(){}
    private static  Fan instance;
    //靜態代碼塊中創建單例對象
    static {
        instance=new Fan();
    }
    public static  Fan getInstance()
    {
        return instance;
    }
    public void on()
    {
        System.out.println("風扇開");
    }
    public  void off()
    {
        System.out.println("風扇關");
    }
}
//子系統角色
public class Light
{
    //靜態常量
    private static  Light  instance=new Light();;
    //構造器私有化
    private  Light(){};
  //共有靜態方法，返回一個實例對象
    public  static  Light getInstance()
    {
        return instance;
    }
    public  void on()
    {
        System.out.println("燈開");
    }
    public  void  off()
    {
        System.out.println("燈關");
    }
}

//外觀角色
public class GeneralSwitchFaced
{
    private Light light;
    private  Fan fan;
  public GeneralSwitchFaced()
    {
        light=Light.getInstance();
        fan=Fan.getInstance();
    }
    public void on()
    {
        light.on();
        fan.on();
    }
    public void off()
    {
        light.off();
        fan.off();
    }
}
//測試
public class Test
{
    @org.junit.Test
    public void test()
    {
        GeneralSwitchFaced faced=new GeneralSwitchFaced();
        faced.on();
        faced.off();
    }
}

實例二：文件加密

某系統需要提供一個文件加密模塊，加密流程包括三個操作，分別是讀取源文件、加密、保存加密之后的文件。讀取文件和保存文件使用流來實現，這三個操作相對獨立，其業務代碼封裝在三個不同的類中?，F在需要提供一個統一的加密外觀類，用戶可以直接使用該加密外觀類完成文件的讀取、加密和保存三個操作，而不需要與每一個類進行交互，使用外觀模式設計該加密模塊。

通過外觀角色的一個方法，封裝了三個獨立的操作過程，即將文件的加密過程封裝在了外觀角色的文件加密方法中，客戶通過調用該方法即可完成對文件的加密，無需挨個調用三個獨立的操作

模式優缺點

優點

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

缺點

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

模式適用環境

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

源碼分析外觀模式的典型應用

(1) 外觀模式應用于JDBC數據庫操作

 public class JDBCFacade {
     private Connection conn=null;
     private Statement statement=null;
     public void open(String driver,String jdbcUrl,String userName,String userPwd) {
         ......
      }
      public int executeUpdate(String sql) {
         ......
      }
     public ResultSet executeQuery(String sql) {
         ......
     }
     public void close() {
         ......
     }
 }

(2) Session外觀模式是外觀模式在Java EE框架中的應用

模式擴展

一個系統有多個外觀類

在外觀模式中，通常只需要一個外觀類，并且此外觀類只有一個實例，換言之它是一個單例類。在很多情況下為了節約系統資源，一般將外觀類設計為單例類。當然這并不意味著在整個系統里只能有一個外觀類，在一個系統中可以設計多個外觀類，每個外觀類都負責和一些特定的子系統交互，向用戶提供相應的業務功能。

不要試圖通過外觀類為子系統增加新行為

不要通過繼承一個外觀類在子系統中加入新的行為，這種做法是錯誤的。外觀模式的用意是為子系統提供一個集中化和簡化的溝通渠道，而不是向子系統加入新的行為，新的行為的增加應該通過修改原有子系統類或增加新的子系統類來實現，不能通過外觀類來實現。

外觀模式與迪米特法則

外觀模式創造出一個外觀對象，將客戶端所涉及的屬于一個子系統的協作伙伴的數量減到最少，使得客戶端與子系統內部的對象的相互作用被外觀對象所取代。外觀類充當了客戶類與子系統類之間的“第三者”，降低了客戶類與子系統類之間的耦合度，外觀模式就是實現代碼重構以便達到“迪米特法則”要求的一個強有力的武器。

抽象外觀類的引入

外觀模式最大的缺點在于違背了“開閉原則”，當增加新的子系統或者移除子系統時需要修改外觀類，可以通過引入抽象外觀類在一定程度上解決該問題，客戶端針對抽象外觀類進行編程。對于新的業務需求，不修改原有外觀類，而對應增加一個新的具體外觀類，由新的具體外觀類來關聯新的子系統對象，同時通過修改配置文件來達到不修改源代碼并更換外觀類的目的。

總結

參考文章

外觀模式

java設計模式之外觀模式(Facade)

總結

本篇文章就到這里了，希望能夠給你帶來幫助，也希望您能夠多多關注服務器之家的更多內容！

原文鏈接：https://blog.csdn.net/m0_53157173/article/details/120085869