為子系統中的一組介面提供乙個一致的介面，外觀模式定義了乙個高層介面，這個介面使得這一子系統更加容易使用。
為了方便理解，我們可以看看下圖，左邊是未使用外觀模式時，外部客戶端直接呼叫企業中的各個子系統，呼叫鏈複雜且混亂，增大了客戶端的使用難度，右邊使用外觀模式後，客戶端直接跟外觀系統互動，而不必再依賴內部子系統了，從客戶端角度來看，呼叫變得簡單了；而從企業系統內部來看，維護也變得容易了。
實際上，外觀模式跟**模式類似，也更偏向於架構模式，常見於企業應用整合中，企業應用整合包括介面整合，業務流程整合（過程整合），控制整合（應用整合，api整合），資料整合四個層面，而外觀模式與業務流程整合（過程整合）密切相關，因為外觀模式有業務流程優化的意味在裡面，因此，外觀模式有時也叫過程模式，例如****首頁就可以看成是乙個外觀模式的應用，因為它是多個系統的整合，並對外提供了乙個一致的介面（不要死板的理解為api介面）。
為乙個複雜的模組或子系統提供乙個一致的外界訪問介面，降低客戶端訪問子系統的複雜度。
使客戶端與子系統之間解耦，讓子系統內部模組更易維護和擴充套件。
進行訪問控制，提高系統安全性。
維護大型遺留系統，小型系統沒必要用外觀，用**就可以了。
極端情況下，假如外觀模式中的子系統只有乙個，就跟**模式差不多了，這有點像抽象工廠模式和工廠方法模式之間的關係。
首先， ddd中的service層是外觀模式，因為它封裝了下層的repository，讓上層更容易使用，同時上層也可以直接訪問repository層。那麼，mvc中的controller層，三層架構中的bll層，微服務中的閘道器是不是外觀模式呢？
controller不算外觀模式，因為controller雖然封裝了service層，但service層本身不能被使用者（controller的上層）直接訪問，因此不是外觀，反而更像介面卡；
bll層也不算外觀模式，雖然從**上看，他跟ddd中的service層非常相似，甚至完全一樣，但三層架構是橫向切分，而ddd是縱向切分，他們從設計思想上有本質的區別。在三層架構中，雖然上層也可以直接訪問到dal層，但這種操作在設計上是不被允許的；
閘道器中用到了外觀模式，閘道器比較複雜，其中大量用到了外觀模式，但不等於外觀模式，因為有時候閘道器也僅僅是個**，並未做業務整合。
當然，在具體開發過程中，沒必要過分拘泥於這些細節，因為滿不滿足外觀模式的定義相對於好的設計而言，是即非充分也非必要條件，但是多思考一些細節卻可以讓自己想的更通透，何樂而不為呢？
原始碼鏈結
設計模式 外觀模式
外觀模式，我的理解就是將複雜的類進行重新封裝，將簡單的介面呈現出來，降低呼叫端和實際類的耦合性。拿 大話設計模式 上邊關於 和 的例子來說。對於不入門的股民來說，交易有些過於龐大，需要學習的東西很多，如果沒整明白就進行投資，很容易賠錢的。很多剛入 的股民都賠的很慘。而買 有提出了乙個新的觀念，我們買...
設計模式 外觀模式
何為外觀模式？外觀模式 為子系統中的一組介面提供乙個一致的介面，此模式定義了乙個高層介面，這個介面使得一子系統更加容易使用。它是一種結構型模式，它主要解決的問題是 元件的客戶和元件中各種複雜的子系統有了過多的耦合，隨著外部客戶程式和 各子系統的演化，這種過多的耦合面臨很多變化的挑戰。uml類圖 乙個...
設計模式 外觀模式
外觀模式說白了就是為一組介面提供乙個一致的介面。例如 定義三個類a b c，每個類各定義乙個方法。class a pubic void showa cout a showa pubic void showb cout b showb pubic void showc cout c showc 定義乙...