標簽： 設計模式初涉

場景引入

相信各位玩過LOL英雄聯盟游戲的童鞋，對下面兩個英雄都不會陌生吧：

分別是瑞雯和盲僧，這兩個英雄都可以通過組合鍵的方式打出爆炸性傷害，
打出這套組合鍵除了需要較快的手速外，還需要記住鍵位順序，對應技能：
瑞雯的光速QA：Q + 空格 + A + 鼠標左鍵 + Q + 空格 + A + 鼠標左鍵 + Q + 空格 + A + 鼠標左鍵
瞎子一秒七腳：Q + A + E + 九頭蛇 + R + A + 閃現 + Q
注：光速QA的空格鍵是設置了大笑動作用來。

我們通過來演示下如何手把手打出這一波操作。

單身20年拼手速

先把各種需要用到的鍵位都列出來：A，E，Q，R，空格，閃現，九頭蛇，鼠標左鍵

接著順序我們依次按下對應按鈕來打出連招

輸出結果

盡管打出了連招，但是，每次按連招都需要把對應的每個鍵都操作一遍，
非常麻煩，而且對于我這種手殘玩家，基本是按不出來的，有沒有辦法，
把每個按鍵的調用集成到一個鍵上，不用關心具體調用順序與內容，只要
通過這個鍵就可以一鍵完成連招呢？當然是有的，通過外觀模式可以
幫我們解決這個需求，我們將按鍵順序(交互)封裝到外掛(外觀類)中。

手殘黨用腳本

非常簡單，就是把調用邏輯抽取到外掛類中，暴露兩個方法供玩家調用：

手殘黨玩家只需直接調用這個腳本即可完成一鍵光速QA和一秒7腳：

輸出結果

用法非常簡單，例子也很好理解，接下來直接上定義吧。

外觀模式概念相關

定義

要求一個子系統的外部與內部的通信必須通過一個統一的對象進行，
外觀模式提供一個高層次的接口，使得子系統更易于使用。
(其實就是封裝，用于解決類與類間的依賴關系，比如本來是：
玩家依賴于：Q，A，E，R等鍵位對象，現在變成只依賴與腳本對象
從而降低了類間的耦合度。)

兩個角色

• Facade：外觀角色，客戶端可以調用他的方法，在外觀角色
  中可以知道相關子系統的功能和責任；在正常情況下，它將所有從客戶
  端發來的請求委派到相應的子系統去，傳遞給相應的子系統對象處理。
• Subsystem：子系統角色，實現子系統的功能，處理外觀類
  指派的任務，注意子系統類不含有外觀類的引用

UML類圖

使用場景

• 為訪問一系列復雜的子系統提供一個簡單的入口
• 客戶端程序與多個子系統間存在很大的依賴性，可以引入外觀模式幫助解耦
• 在層次化結構中，可以使用外觀模式定義系統中每一層的入口，層與層間不
  直接產生聯系，而通過外觀類進行關聯，降低層間的耦合度。

優缺點

優點：

• 降低客戶端與子系統間的耦合度；
• 對客戶屏蔽子系統組件，從而能簡化接口，減少客戶端處理的對象數目；
• 一個子系統的修改對其他子系統沒有任何影響，而且子系統內部變化也不會影響到外觀對象

缺點：

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

本節代碼：

https://github.com/coder-pig/DesignPatternsExample/tree/master/10.Facade%20Pattern