門面模式也叫外觀模式，是一種比較常用的封裝模式，其定義如下:
要求乙個子系統的外部與其內部的通訊必須通過乙個統一的物件進行。門面模式提供乙個高層次的介面，使得子系統更易於使用。
客戶端可以呼叫這個角色的方法。此角色知曉子系統的所有功能和責任。一般情況下，本角色會將所有從客戶端發來的請求委派到相應的子系統去，也就是說該角色沒有實際的業務邏輯，只是乙個委託類。
可以同時有乙個或者多個子系統。每乙個子系統都不是乙個單獨的類，而是乙個類的集合。子系統並不知道門面的存在。對於子系統而言，門面僅僅是另外乙個客戶端而已。
門面模式有如下優點:
(1)減少系統的相互依賴
想想看，如果我們不使用門面模式，外界訪問直接深入到子系統內部，相互之間是一種強耦合關係，你死我就死，你活我才能活，這樣的強依賴是系統設計所不能接受的，門面模式的出現就很好地解決了該問題，所有的依賴都是對門面物件的依賴，與子系統無關。
(2)提高了靈活性
依賴減少了，靈活性自然提高了。不管子系統內部如何變化，只要不影響到門面物件，任你自由活動。
(3)提高安全性
想讓你訪問子系統的哪些業務就開通哪些邏輯，不在門面上開通的方法，你休想訪問到。
門面模式最大的缺點就是不符合開閉原則，對修改關閉，對擴充套件開放。一旦在系統投產後發現有乙個錯誤，你怎麼解決？完全遵從開閉原則，根本沒辦法解決。繼承？覆寫？都頂不上用，唯一能做的一件事就是修改門面角色的**，這個風險相當大，這就需要大家在涉及的時候慎之又慎，多思考幾遍才會有好收穫。
(1)門面已經龐大到不能忍受的程度
比如乙個純潔的門面物件已經超過了200行的**，雖然都是非常簡單的委託操作，也建議拆分成多個門面，否則會給以後的維護和擴充套件帶來不必要的麻煩。那麼怎麼拆分？按照功能拆分是乙個非常好的原則，比如乙個資料庫操作的門面可以拆分為查詢門面、刪除門面、更新門面等。
(2)子系統可以提供不同訪問路徑
我們以門面模式的通用源**為例。classa、classb、classc是乙個子系統中的3個物件，現在有兩個不同的高層模組來訪問該子系統，模組一可以完整的訪問所有業務邏輯，也就是通用**中的facade類，它是子系統的信任模組;而模組二屬於受限訪問物件，只能訪問methodb方法，那該如何處理呢？在這種情況下，就需要建立兩個門面以供不同的高層模組來訪問，在原有的通用原始碼上增加乙個新的門面即可。
在門面模式中，門面角色應該是穩定，它不應該經常變化，乙個系統一旦投入執行它就不應該被改變，它是乙個系統對外的介面，你變來變去還怎麼保證其他模組的穩定執行呢？但是，業務邏輯是會經常變化的，我們已經把它的變化封裝在子系統內部，無論你如何變化，對外界的訪問者來說，都還是同乙個門面，同樣的方法–這才是架構師最希望看到的結構。
門面模式是乙個很好的封裝方法，乙個子系統比較複雜時，比如演算法或者業務比較複雜就可以封裝出乙個或多個門面出來，專案的結構簡單，而且擴充套件性非常好。還有，對於乙個較大專案，為了避免人員帶來的風險，也可以使用門面模式，技術水平比較差的成員，盡量安排獨立的模組，然後把他寫的程式封裝到乙個門面裡，盡量讓其他專案成員不用看到這些人的**，看也看不懂。使用門面模式後，對門面進行單元測試，約束專案成員的**質量，對專案整體質量的提公升也是乙個比較好的幫助。
**例子:
設計模式之門面模式
coding gbk coding utf 8 author edgar 這是門面模式的乙個應用場景。具體故事情節請見 設計模式之禪 門面模式把一套方法封裝起來，使用者不需要知道具體的實現細節。class letterprocessimpl object def writecontext self,...
設計模式之門面模式
模式定義 為子系統中的一組介面提供乙個統一的高層介面，使子系統更容易使用。該模式通過外觀介面與子系統 互動，而不與具體的子系統中的細節互動。分層結構 mvc web應用中的三層結構 遵循原則 迪公尺特原則 最少知識原則，你不需要知道的你就不要知道，你知道幹什麼？封裝變化部分。適用場合 1 乙個系統複...
設計模式之門面模式
外觀模式定義了乙個高層介面，讓子系統更容易使用 結構性場景 有個 允許使用者用自己的積分來兌換商店內禮物，兌換需要經過校驗積分，支付積分，生成訂單的過程，單對呼叫兌換積分的介面來說不用關心裡面的三個過程，只需關心呼叫兌換積分的介面 新建積分兌換禮物實體類 package com.tangbaobao...