設計模式學習以外觀模式

UML結構類圖的經常使用畫法

簡單工廠

Demo傳送門

案例：有ModuleA，ModuleB，ModuleC三個類，這三個類實現三個不一樣的方法 1.按照普通思路，客戶端若是想要和這三個類打交道，通常的作法就是直接引入三個類，分別進行實例化，而後引用三個類中的方法 2.採用外觀模式，客戶端無需知道這三個類的存在，只須要和外觀層進行交互便可

下面先講解一下采用普通方法的實現

1.定義接口

爲了更加深入的體會面向協議編程，我這裏採用的都是協議方式，上述三者是定義了A,B,C三者的協議(用協議的好處是面向對象，後續增長新的協議方法比較方便集中管理)

2.實現協議

3.客戶端調用

咱們能夠看到，用普通方法進行實現的時候，客戶端必需要知道每個類(即引入全部的頭文件)，如此一來客戶端和各個實現類的關係耦合度就太大了，不利於擴展修改，同時也不知足接口隔離的原則，若是實現類新增或者改變了，客戶端也要作相應的改變。 那麼若是想要隔離客戶端與各個子模塊實現類的交互該怎麼辦呢？

外觀模式就很好地解決了這個難題，下面從一張UML圖來看外觀模式：

客戶端從始至終只須要和Facade進行打交道

外觀模式實現

接口定製和子模塊的具體實現前面已經有了，這裏只須要看下外觀類和客戶端調用便可

外觀類實現

咱們看到普通方法中的客戶端調用的實現到了這裏來了

客戶端調用

客戶端調用更加清爽了

下面詳細講述一下什麼是外觀模式。 相信看到這裏，咱們也能大體推測出，外觀模式無非就是一層外衣，包裹住裏面的子模塊，客戶端接觸的只有這一層外衣，具體裏面是什麼，實現了什麼，徹底不用管，子模塊和客戶端的解耦也是很完全的.

外觀模式不是爲了給子模塊添加新的功能接口，而是讓外部與內部子模塊的耦合度下降，它只是用來包裝已有的功能，負責組合已有功能來實現客戶端的須要，說白了就是我有N多個功能模塊，如今我有一個需求須要實現這些模塊中的某幾個，那就能夠用外觀來包一下供給外界使用。

前面也能夠看到外觀模式無非就是把客戶端代碼搬到了外觀類中，由外觀類包裝，客戶端調用，然而本質上是有變化的。外觀類所在層面不是客戶端，而是系統(組件),它屏蔽了客戶端和內部模塊的交互，將各個子模塊組合成爲一個總體，封裝了內部具體的實現細節，方便了外界的調用。此外，外觀模式的功能還能夠被多個客戶端調用，若是有N個客戶端實現的功能模塊同樣，直接調用外觀類便可，這樣就實現了很好地複用，外觀模式的本質就是，封裝交互，簡化調用，體現了最少知識原則

下面說一下外觀模式的優缺點：

優勢

• 鬆耦合
• 簡單易用
• 更好地劃分訪問層次

缺點

• 過多的或者不合理的facade容易讓人迷惑