設計模式以外觀模式-總結

設計模式以外觀模式-總結

在上一篇中，咱們模擬家庭影院項目實現了外觀模式講解。本篇咱們對外觀模式進行總結。

來源：凱哥Java(kaigejava).本文由凱哥《23設計模》系列中的一篇。

凱哥忽然感受，使用家庭影院這個例子不恰當。換個通俗易懂的。去銀行存取錢。這個案例你們都遇到過吧。

咱們去銀行後，每一個窗口都有個漂亮的爲各位服務。在咱們存取錢的過程當中，只須要和窗口溝通就能夠了。咱們把IDcard給、輸入密碼而後就會給你須要取得錢。咱們來分析這個過程。

存取錢用戶相對於銀行系統來講，是外部人員(系統)，窗口服務員就是銀行對外提供得一個交互窗口。咱們把須要得IDCard、銀行卡、密碼輸入以後，窗口服務員就會給咱們打印收據、取錢、請領導簽字(若是取錢額度較大得話)等等操做，窗口服務員都幫咱們處理完了。最後，咱們返回給咱們得是咱們須要取得現金或者存得憑證。

咱們來分析角色：

外部調用系統(或者客戶端)：如使用遙控器控制影院得人或去銀行存取錢得咱們

複雜系統：如影院相關得或者銀行系統

在複雜系統中，內部子系統：

銀行例子中的：驗鈔機、打印機、保險箱、銀行領導等。

咱們爲何要使用外觀模式？能解決什麼問題？

下降了訪問複雜系統的內部的複雜聯繫。

如何理解這句話？

去銀行取錢，若是沒有窗口服務，咱們須要本身數錢、本身找打印機、本身找銀行領導簽字等等。是否是很麻煩。有了窗口服務員，咱們自須要和服務員交換，其餘都不用關了。

因此，咱們能夠獲得外觀模式的關鍵代碼在於：當客戶端和複雜系統之間進行交換的時候，在二者之間在封裝添加一層，這一層的做用就是將調用順序、依賴關係等等都處理好的。

優勢：

減小了系統之間的相互依賴關係、提升了系統的靈活性、提升了系統的安全性(想一想若是去銀行取錢，讓你本身從保險櫃中拿錢這感受~)；

客戶端不之間和複雜系統耦合，使用外觀類和系統進行耦合，下降了耦合性；

預防低水平的開發人員帶來的風險

缺點：

不符合軟件設計的開閉原則，若是，須要修改東西，就要修改對外的窗口，很麻煩，繼承重寫都是不合適的。

使用場景：

爲一個複雜的模塊或者是子系統提供外界訪問的模塊；

子系統相對獨立的

外觀模式的目的：

爲子系統中的一組接口或者一組功能提供一個一致的接口(界面)，外管模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。

本文來源：凱哥Java(kaigejava)

凱哥我的博客：www.kaigejava.com

本文地址：http://kaigejava.com/gwjeesns/article/edit/567

應用實例：

若是家庭影院以及銀行取錢例子還很差理解。那麼最簡單的，JAVA中三層開發模式(MVC)就是典型的外觀模式。這下是否是就好理解了.