23種設計模式+額外常用設計模式匯總 (持續更新）

外部與一個子系統的通信必須通過一個統一的外觀（Facade）對象進行，這就是外觀模式。

• 外觀模式要求一個子系統的外部與其內部的通信必須通過一個統一的外觀（Facade）對象進行。外觀模式提供一個高層次的接口，是的子系統更易于使用。
• 外觀模式的外觀類將客戶端與子系統的內部復雜性分隔開，使得客戶端只需要與外觀對象打交道，而不需要與子系統內部的很多對象打交道。

外觀模式的結構

• 外觀（Facade）角色
  客戶端可以調用這個角色的方法。此角色知曉相關的（一個或者多個）子系統的功能和責任。在正常情況下，本角色會將所有從客戶端發來的請求委派到相應的子系統去。
• 子系統（subsystem）角色
  可以同時有一個或者多個子系統。每一個子系統都不是一個單獨的類，而是一個類的集合。每一個子系統都可以被客戶端直接調用，或者被門面角色調用。子系統并不知道門面的存在，對于子系統而言，門面僅僅是另外一個客戶端而已。

【GOF】的書中指出
在外觀模式中，通常只需要一個外觀類，并且此外觀類只有一個實例，換言之它是一個單例類。當然這并不意味著在整個系統里只能有一個外觀類，而僅僅是說對每一個子系統只有一個外觀類?；蛘哒f，如果有一個系統有好幾個子系統的話，每一個子系統有一個外觀類，整個系統可以有數個外觀類。

當客戶程序與抽象類的實現部分之間存下著很大的依賴性，引入Facade將這個子系統與客戶一集其他的子系統分離，為一個復雜子系統提供一個簡單接口，Facade可以提供一個簡單地缺省視圖，這一視圖對大多數用戶來說已經足夠，而那些需要更多的可定制性的用戶可以越過Facade層。可以提高子系統的獨立性和可移植性。

• 在層次化結構中，可以使用Facade模式定義系統中每一層的入口點，如果子系統之間是相互依賴的，則可以讓他們僅通過Facade進行通信，從而簡化他們之間的依賴關系。
• 希望包裝或隱藏原有系統：Facade可以把原有系統作為自己的私有成員。原有系統與Facade類聯系在一起，但使用Facade類的客戶無法看到原有的系統。
  維護一個一流的大型系統。
  跟蹤對系統的使用——強迫所有客戶通過Facade使用原有系統。

優點

• 屏蔽了外部客戶端和系統每部模塊的交互
• Facade的功能可以被多個客戶端調用，可以實現復用（功能的共享）
• 對使用Facade的人員來說，Facade大大的節省了他們的學習成本。

缺點

不符合開閉原則。

本質
封裝交互、簡化調用
就是將各種方法封裝到門面類中，用戶只能看到門面類，也不需要知道真實的方法類，做到了隔離。

實現：

public class ModuleA {//示意方法public void MethodA(){System.out.println("調用ModuleA中的MethodA方法");} } public class ModuleB {//示意方法public void MethodB(){System.out.println("調用ModuleB中的MethodB方法");} } public class ModuleC {//示意方法public void MethodC(){System.out.println("調用ModuleC中的MethodC方法");} } 門面角色類：public class Facade {//示意方法，滿足客戶端需要的功能ModuleA a；ModuleA b;ModuleA c;Facade(){a = new ModuleA();b = new ModuleB();c = new ModuleC();}public void MethodA(){a.MethodA();b.MethodB();}public void MethodB(){b.MethodB();c.MethodC();} } 客戶端角色類：public class Client {public static void main(String[] args) {Facade facade = new Facade();facade.MethodA();facade.MethodB();}}

總結

以上是生活随笔為你收集整理的『设计模式』外观模式--这篇博客也太明了吧的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。