設計模式以外觀模式

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

不知道你們有沒有比較過本身作飯和去參觀吃飯的去邊，若是本身作飯須要自行準備作飯的材料，鍋、油鹽醬醋等，可是若是去飯店吃飯的話那就不同了，服務員會給你一個菜單，你告訴服務員要吃什麼菜，而後服務員去下單。也就是由於飯店有服務員的存在，咱們不須要直接和這些材料直接的接觸，整個作飯的過程由飯店廚師來完成，咱們只須要與服務員進行簡單的溝通就行了，整個過程很是的省事。

什麼是外觀模式

外觀模式：亦稱「過程模式」。學校課程評價模式之一。美國教育學者斯泰克1967年在所著《教育評價的外觀》中提出。主張按照描述和判斷資料來評價課程，關鍵的活動是在課程實施的全過程當中進行觀察和蒐集意見，以瞭解人們對課程的不一樣見解。這種模式不限於檢查教學的成果，重視描述和判斷教學過程當中各類複雜、動態的現象和事物。 —— 節選自百度百科

外觀類爲包含許多活動部件的複雜子系統提供一個簡單的接口。與直接調用子系統相比，外觀提供的功能可能比較有限， 但它卻包含了客戶端真正關心的功能。若是你的程序須要與包含幾十種功能的複雜庫整合， 但只需使用其中很是少的功能， 那麼使用外觀模式會很是方便。

外觀模式中一個子系統的外部與其內部的通訊經過一個統一的外觀類進行，外觀類將客戶類與子系統的內部複雜性分隔開，是的客戶類只須要與外觀角色打交道，而不須要與子系統內部的不少對象打交道。

外觀模式優缺點

在團隊協做時，咱們每一個人都會負責不一樣的模塊，有些模塊可能會被拆解成更多的子模塊。不是模塊負責人，可能很難搞清楚這些細碎的小模塊要如何作合起來完成工做。這個時候，咱們也能夠提供外觀模式的總接口，這樣，負責其它模塊的同事不須要搞清楚個人模塊的內在邏輯，他只須要引用個人外觀模式類，而後調用那個類裏的方法，就能完成工做。

優勢

1. 下降了子系統與客戶端之間的耦合度，使得子系統的變化不會影響調用它的客戶類
2. 對客戶屏蔽了子系統組件，減小了客戶處理的對象數目，並使得子系統使用起來更加容易
3. 下降了大型軟件系統中的編譯依賴性，簡化了系統在不一樣平臺之間的移植過程，由於編譯一個子系統不會影響其餘的子系統，也不會影響外觀對象

缺點

1. 不能很好地限制客戶使用子系統類，很容易帶來未知風險
2. 增長新的子系統可能須要修改外觀類或客戶端的源代碼，違背了開閉原則

示例

外觀模式的主要角色以下：

1. 外觀：提供了一種訪問特定子類系統功能的便捷方法，其瞭解如何重定向客戶端請求，知曉如何操做一切活動部件
2. 建立附加外觀：類能夠避免多種不相關的功能，污染單一外觀，使其變成有一個複雜結構，客戶端和其餘外觀均可以使用附加外觀
3. 複雜子系統：由數十個不一樣的對象構造。若是要用這些對象完成有意義的工做，你必須深刻了解子系統的實現細節，好比按照正確順序初始化對象和爲其提供正確的格式數據
4. 客戶端：使用外觀代替對子系統的直接調用

類圖以下所示：

代碼示例：

class SubSystemA {

  public MethodA():void{
    console.log("SubSystemA:業務實現代碼")
  }

}

class SubSystemB {

  public MethodB():void{
    console.log("SubSystemB:業務實現代碼")
  }

}

class Facade {
  private obj1:SubSystemA = new SubSystemA();
  private obj2:SubSystemB = new SubSystemB();

  public Method():void  {
    this.obj1.MethodA();
    this.obj2.MethodB();
  }
}

class Program {

  private facade:Facade = new Facade();

  public start():void {
    this.facade.Method();
  }

}

const program = new Program();
program.start();

總結

外觀模式從總體來講仍是相對比較好理解，這種思想再平常開發中應用場景有不少，從使用體驗來講，外觀模式和語法糖很像。使用外觀模式，能夠大大減小咱們糾纏在語法實現的時間消耗，更容易專一於業務邏輯。

一樣的，對於一些咱們並不清楚內在邏輯的功能，外觀模式還能賦予咱們更強的實現能力，讓咱們更專一在本身負責的模塊，提升團隊協做的效率。