設計模式筆記：面板模式

標籤：

面板模式我的理解：

• 面板模式為子系統整合出一個統計的對外介面，提供可和使用。
  
• 【不增加新的行為】
  
• 與中介模式 有一定類似，不過面板模式 只能單方向的調用使用；
  
• 與適配器模式 相比，面板模式只是提供統一介面，不進行介面轉換。
  

2016年4月16日概述：面板模式，我們通過外觀的封裝，使應用程式只能看到外觀對象，而不會看到具體的細節對象，這樣無疑會降低應用程式的複雜度，並且提高了程式的可維護性。

例子1：一個電源總開關可以控制四盞燈、一個風扇、一台空調和一台電視機的啟動和關閉。該電源總開關可以同時控制上述所有電器裝置，電源總開關即為該系統的面板模式設計。

類圖：【把各種的類，介面都統一出來，弄成一個對外的統計介面】
模式組成：

• 外觀角色（Facade）：是模式的核心，他被客戶client角色調用，知道各個子系統的功能。同時根據客戶角色已有的需求預訂了幾種功能組合\
  
• 子系統角色（Subsystem classes）：實現子系統的功能，並處理由Facade對象指派的任務。對子系統而言，facade和client角色是未知的，沒有Facade的任何相關資訊；即沒有指向Facade的執行個體。
  
• 客戶角色（client）：調用facade角色獲得完成相應的功能。

方案：為子系統中的一組介面提供一個一致的介面， Facade模式定義了一個高層介面，這個介面使得這一子系統更加容易使用。引入外觀角色之後，使用者只需要直接與外觀角色互動，使用者與子系統之間的複雜關係由外觀角色來實現，從而降低了系統的耦合度。
效果：

Facade模式有下面一些優點：

1）對客戶屏蔽子系統組件，減少了客戶處理的對象數目並使得子系統使用起來更加容易。通過引入面板模式，客戶代碼將變得很簡單，與之關聯的對象也很少。2）實現了子系統與客戶之間的松耦合關係，這使得子系統的組件變化不會影響到調用它的客戶類，只需要調整外觀類即可。3）降低了大型軟體系統中的編譯依賴性，並簡化了系統在不同平台之間的移植過程，因為編譯一個子系統一般不需要編譯所有其他的子系統。一個子系統的修改對其他子系統沒有任何影響，而且子系統內部變化也不會影響到外觀對象。4）只是提供了一個訪問子系統的統一入口，並不影響使用者直接使用子系統類。Facade模式的缺點 :1） 不能很好地限制客戶使用子系統類，如果對客戶訪問子系統類做太多的限制則減少了可變性和靈活性。2） 在不引入抽象外觀類的情況下，增加新的子系統可能需要修改外觀類或用戶端的原始碼，違背了“開閉原則”。
總結：

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

2）面板模式也是“迪米特法則”的體現，通過引入一個新的外觀類可以降低原有系統的複雜度，外觀類充當了客戶類與子系統類之間的“第三者”，同時降低客戶類與子系統類的耦合度。面板模式就是實現代碼重構以便達到“迪米特法則”要求的一個強有力的武器。

3）面板模式要求一個子系統的外部與其內部的通訊通過一個統一的外觀對象進行，外觀類將用戶端與子系統的內部複雜性分隔開，使得用戶端只需要與外觀對象打交道，而不需要與子系統內部的很多個物件打交道。

4）面板模式從很大程度上提高了用戶端使用的便捷性，使得用戶端無須關心子系統的工作細節，通過外觀角色即可調用相關功能。5）不要試圖通過外觀類為子系統增加新行為 ，不要通過繼承一個外觀類在子系統中加入新的行為，這種做法是錯誤的。面板模式的用意是為子系統提供一個集中化和簡化的溝通渠道，而不是向子系統加入新的行為，新的行為的增加應該通過修改原有子系統類或增加新的子系統類來實現，不能通過外觀類來實現。

模式擴充：

一個系統有多個外觀類：        在面板模式中，通常只需要一個外觀類，並且此外觀類只有一個執行個體，換言之它是一個單例類。在很多情況下為了節約系統資源，一般將外觀類設計為單例類。當然這並不意味著在整個系統裡只能有一個外觀類，在一個系統中可以設計多個外觀類，每個外觀類都負責和一些特定的子系統互動，向使用者提供相應的業務功能。不要試圖通過外觀類為子系統增加新行為：       不要通過繼承一個外觀類在子系統中加入新的行為，這種做法是錯誤的。面板模式的用意是為子系統提供一個集中化和簡化的溝通渠道，而不是向子系統加入新的行為，新的行為的增加應該通過修改原有子系統類或增加新的子系統類來實現，不能通過外觀類來實現。面板模式與迪米特法則：       面板模式創造出一個外觀對象，將用戶端所涉及的屬於一個子系統的協作夥伴的數量減到最少，使得用戶端與子系統內部的對象的相互作用被外觀對象所取代。外觀類充當了客戶類與子系統類之間的“第三者”，降低了客戶類與子系統類之間的耦合度，面板模式就是實現代碼重構以便達到“迪米特法則”要求的一個強有力的武器。

抽象外觀類的引入：

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

設計模式筆記：面板模式