uml結構類圖的常用畫法
簡單工廠
demo傳送門
案例：有modulea，moduleb，modulec三個類，這三個類實現三個不同的方法 1.按照普通思路，客戶端如果想要和這三個類打交道，一般的做法就是直接引入三個類，分別進行例項化，然後引用三個類中的方法 2.採用外觀模式，客戶端無需知道這三個類的存在，只需要和外觀層進行互動即可下面先講解一下採用普通方法的實現
1.定義介面
為了更加深刻的體會面向協議程式設計，我這裡採用的都是協議方式，上述三者是定義了a,b,c三者的協議(用協議的好處是物件導向，後續增加新的協議方法比較方便集中管理)
2.實現協議
3.客戶端呼叫
我們可以看到，用普通方法進行實現的時候，客戶端必須要知道每乙個類(即引入所有的標頭檔案)，如此一來客戶端和各個實現類的關係耦合度就太大了，不利於擴充套件修改，同時也不滿足介面隔離的原則，如果實現類新增或者改變了，客戶端也要做相應的改變。 那麼如果想要隔離客戶端與各個子模組實現類的互動該怎麼辦呢？
外觀模式就很好地解決了這個難題，下面從一張uml圖來看外觀模式：
客戶端從始至終只需要和facade進行打交道
介面定製和子模組的具體實現前面已經有了，這裡只需要看下外觀類和客戶端呼叫即可
外觀類實現
我們看到普通方法中的客戶端呼叫的實現到了這裡來了
客戶端呼叫
客戶端呼叫更加清爽了
下面詳細講述一下什麼是外觀模式。 相信看到這裡，我們也能大致推測出，外觀模式無非就是一層外衣，包裹住裡面的子模組，客戶端接觸的只有這一層外衣，具體裡面是什麼，實現了什麼，完全不用管，子模組和客戶端的解耦也是很徹底的.
外觀模式不是為了給子模組新增新的功能介面，而是讓外部與內部子模組的耦合度降低，它只是用來包裝已有的功能，負責組合已有功能來實現客戶端的需要，說白了就是我有n多個功能模組，現在我有乙個需求需要實現這些模組中的某幾個，那就可以用外觀來包一下供給外界使用。
前面也可以看到外觀模式無非就是把客戶端**搬到了外觀類中，由外觀類包裝，客戶端呼叫，然而本質上是有變化的。外觀類所在層面不是客戶端，而是系統(元件),它遮蔽了客戶端和內部模組的互動，將各個子模組組合成為乙個整體，封裝了內部具體的實現細節，方便了外界的呼叫。此外，外觀模式的功能還可以被多個客戶端呼叫，如果有n個客戶端實現的功能模組一樣，直接呼叫外觀類即可，這樣就實現了很好地復用，外觀模式的本質就是，封裝互動，簡化呼叫，體現了最少知識原則
下面說一下外觀模式的優缺點：
優點
缺點
設計模式之外觀模式
外觀模式提供了乙個統一的介面，用來訪問子系統中的一群介面。這樣可以避免客戶端和子系統之間的緊耦合。這種模式需要將一系列的子系統組合到外觀中，然後將具體的工作交給各個子系統去完成。如此一來，可以簡化介面的呼叫。其本質就是將系統與客戶端互動的地方封裝起來。這個模式，總體來說，很簡單，理解起來也不困難。依...
設計模式之外觀模式
外觀模式 為子系統中的一組介面提供乙個一直的介面，此模式定義了乙個高層介面，這個介面使得這一子系統更加容易使用。即通過乙個中類來完成客戶端的請求。拿機房收費系統的上機過程來說，上機需要顯示上機者的資訊，填寫上機狀態表，填寫上機記錄表。而使用者不需要知道這些功能是怎麼實現的，只需要通過介面操作就可以完...
設計模式之外觀模式
外觀模式，為子系統中的一組介面提供乙個一致的介面，此模式定義了乙個高層介面，這個介面使得這一子系統更加容易使用。在設計初期階段，應該要有意識的將不同的兩個層分離，比如經典的三層架構，層與層之間建立外觀facade。在開發階段，子系統往往因不斷的重構演化而變得越來越複雜，增加外觀模式可以提供乙個簡單的...