在工作3年之後，也算寫了一點代碼。在每天的工作中，越來越感覺‘設計模式’才是程序員的內功心法，是每個程序員最應該花時間鉆研的“九陽神功”。從博客和公眾號推送中，也經常能看到關於設計模式的內容，總是隱隱地感覺那些文章缺少了點什麽，自己也說不清楚，可能是那些文章有種冷冰冰的感覺，沒有溫度。世上最有溫度的文章還是自己寫的，就像永遠都覺得自己做的菜挺好吃一樣。

借著這個機會，也為了提高下自己的編程水平與寫作水平，我想寫一個關於設計模式的專題，有空就更新一下，就當自己練筆了。雖然可能很慢，最後肯定會更新完成的，平時的工作確實也挺繁重的。

寫這些文章的目的，還是希望能把設計模式說的自己能理解，別人也能理解，能夠真正地運用到平時的工作之中。同時也不希望在自己的文章中追求華麗的排版，精致的配圖，因為看過很多這種文章，浪費過多的精力不說，其實也沒有什麽用。最好的效果就是大家都能用簡單的例子說清楚設計模式的使用方法，為什麽要使用設計模式等問題？

本人研究設計模式也有一段時間了，並不希望因為寫文章就暫停自己的腳步，因此本專題的開篇之作就從現在看到的‘外觀模式’開始。

提到‘外觀模式’之前，需要知道一下迪米特法則

如果兩個類不必彼此直接通信，那麽這兩個類就不應當發生直接的相互作用。如果其中一個類需要調用另一個類的某一個方法的話，可以通過第三者轉發這個調用。

這個法則強調的是在類的機構設計上，每一個類都應當盡量降低成員的訪問權限，實現類之間的松耦合。類之間的耦合越弱，越有利於復用。一個弱耦合的類被修改，不會對有管理的類造成波及。

外觀模式

提供了一個統一的接口，用來訪問子系統中的一群接口。外觀定義了一個高層接口，讓子系統更容易使用。

行了，外觀模式下次再詳s看，這次就看懂上面的迪米特法則就可以了。

設計模式(一)