大概花了一個半月的時間把市面上比較知名的設計模式類的書全部買回來學習了一遍，這些書裡面有好有壞。

如果想系統的學習設計模式，我建議還是買書看，因為書上的知識比較系統和權威，不像網上的文章良莠不齊，雖然有很多有些的博客的文章不錯，但是剛開始自學也沒有能力去分辨。

這篇文章應該算是學習設計模式的預熱，讓你對設計模式有一個大概的了解。

後續我會把大部分設計模式單獨成文，這些文章的代碼和文字是我糅合這些書籍加上自己的理解寫出來的，如有偏差，歡迎指正。

什麼是設計模式

定義：

在軟件開發中，經過驗證的，用於解決在特定環境下，重復出現的特定的問題的解決方案。

注意上面的提到的限定詞，下面來詳細說下

1、軟件開發：
其實各行各業都有模式可以套用，這裡的設計模式指的是在軟件開發領域

2、經過驗證的：
必須是經過大家公認和驗證過的解決方案才算得上是設計模式，而不是每個人隨便總結的解決方案都能算

3、特定環境：
必須是在某個特定環境才可以使用該設計模式，因為不同的環境，就算同樣的問題，解決方案也不同，所以不能脫離環境去談使用設計模式

4、重復出現：
因為只有重復出現的問題才有必要總結經驗，形成固定的解決方案，再次遇到這樣的問題就不用從頭開始尋找解決方案，而是直接套用就可以了。

5、特定問題：
軟件開發領域沒有銀彈，不要指望一種設計模式就能包治百病。每種模式只是針對特定問題的解決方案，所以不要迷信設計模式，濫用設計模式。

每個設計模式的構成如下：

1、模式名稱：模式的一個好記的名字

2、環境和問題：描述在什麼環境下，出現什麼特定的問題

3、解決方案：描述如何解決問題

4、效果：描述應用模式後的效果，以及可能帶來的問題

為什麼要學習設計模式

引用知乎上面的一段話：

這段話很好的總結了設計模式的學習路徑，這是在你長時間浸淫在編程領域，然後自己某天頓悟了，這需要足夠的長的時間和悟性。但是現在有了設計模式，可以讓你借用前人總結好的經驗，更快的理解編程思想。

我們都知道面向對象設計的六大原則SOLID，只要遵循這些原則，就可以達到了代碼復用、增加可維護性的目的，從而增加重用性，易於修改，後期可擴展。

但是這寫原則太過於抽象，你沒有幾年的項目實戰，是沒法領悟透徹的，這還需要悟性。

如果說SOLID是軟件開發的內功，那麼設計模式就是武功招式，把SOLID原則表現出來的招式，把思想轉化為實際場景中應用的代碼。

通過學習這些設計模式，讓你找到“封裝變化”、“松耦合”、“針對接口編程”的感覺，從而設計出易維護、易復用、擴展性好、靈活性足的程序。

高手都是先模仿，然後領悟，最後自創。俗話說的“熟讀唐詩三百首”就是這個道理。

不是說你學會了這23種設計模式（設計模式也不止這23種）你就能解決軟件領域的任何問題了，而是通過學習設計模式讓你領悟面向對象編程的思想（SOLID），到最後就可以拋棄設計模式，把這些思想應用在你的代碼中，寫出高內聚、低耦合、可擴展、易維護的代碼了。此時已然是心中無設計模式，而處處是設計模式了。這就是學習設計模式的目的。

學完設計模式只是第一步，並不會讓你的編碼水平有了質的飛躍，接下來需要你通過大量實踐來消化這些設計模式的精髓，內化為自己的思想，從而體現在代碼上。

如何學習設計模式

下面的都是摘抄自《研磨設計模式》一書

1. 學習設計模式的三個層次

2.如何學習設計模式

學習建議

如果你看完上面的內容，覺得很有必要學習設計模式來提高自己的內功，那麼可以接著看下去。

我的學習建議如下，也是對這幾本書的評價吧，大家可以做個參考

1. 《head first設計模式》，推薦指數：????????

建議反復閱讀，然後把所有代碼手動實現一次。雖然這本書是用java語言寫的，如果有其他語言基礎，看起來基本上沒什麼難度。

這本書真正做到了深入淺出，用簡單易懂的語言把設計模式這種抽象程度非常高的知識講的非常透徹。但是估計很多人看不慣這種漫畫風和對話方式的書寫方式，但是你適應了，就發現其實這種方式比純文字書寫，學習起來效率更高。因為人的大腦對於圖像的記憶總是比文字記憶更加深刻，但是這本書並沒有把23種設計模式講完。

2. 《研磨設計模式》，推薦指數：??????????

如果要給這幾本書打評分的話，這本書我想給滿分，真想不到國人也能寫出如此好的技術書籍。這本書出彩的地方在於不僅詳細講解了GOF的23種設計模式，而且寫作的方式我覺得非常好。

首先拋出一個實際問題，然後列出常規的解決方案，接著之處常規的解決方案會有什麼問題，自然而然的引出對應的設計模式來解決。這樣有個比較過程，可以很好的幫助我們理解為什麼要使用設計模式。

這本書之所以如此出彩，大概有如下幾點：

1. 在於書上的大多數例子解決的是開發中遇到的實際問題，雖然都是java後端的，對我們iOS端沒什麼大的意義，但是我們可以從中學習到使用設計模式解決問題的思路，從而領悟到該模式的精髓，大有裨益。

2. 對每個模式進行了深入的擴展，其他書要麼是把用模式模擬下偽代碼，要麼就是講解的不夠深入。但是這本書基本上對每個模式都做到深入講解，分析每個模式的利弊，適用場景，如果變形使用

3.  對於每個模式，都講解了如何和其他模式聯合使用，對於相似的模式，也做了比較詳細的比較。

基於以上三點，我覺得這本書當之無愧的全場最佳。但是非常的遺憾的是，這本書的紙質版網上基本上買不到了，估計銷量不好，出版社不出書了，本來想買一本珍藏起來，時常翻閱，恐不能遂願了，不得不說遺憾。這本書雖然沒有其他書籍名氣那麼大，但是從內容上來說，當屬最優秀的。如果你只想看一本書的話，我推薦這本書，必看！！

3. 《設計模式之禅》，推薦指數：????

這本書的內容對不起這個書名，乍一看這書名應該是對設計模式做了深入研究的。但是真正打開一看，發現每篇都是淺嘗辄止，甚至直接給你拋出一個設計模式的偽代碼，也不講解下為什麼這麼寫。有的篇章舉得例子也是非常不恰當，強行把例子和設計模式扯上關系，不倫不類。

甚至作者在前言裡面提到的本書的精華部分：設計模式和擴展。只是寥寥數筆帶過，說了和沒說一樣。至於本書的殺手锏：設計模式PK和設計模式混編。也是一般般，不過爾爾。

當然本書也不是一無是處，第一部分，我覺得是這本書的精華，詳細解釋了SOLID設計原則，可以好好看看。本篇博文的SOLID部分也是借鑒這本書的。

4.《大話設計模式》，推薦指數：??????

這本書應該算是所有書裡面最淺顯易懂的，如果你閱讀其他的書籍有困難，可以先看這本書。但是這本書講的非常淺顯，僅僅能讓你認識下每個設計模式的實現偽代碼和作用，看完了有個大概了解，沒有做進一步講解。

雖然這本書的網上評價很高，但是我覺得沒必要讀。原因就是真的太淺顯了，看完了對設計模式還是霧裡看花，懵懵懂懂。要入門的話，推薦看head first。

5. 《設計模式》，推薦指數：????????

這本書是其他書籍的鼻祖，GOF原創。但是這本書寫的非常簡練，加之代碼都是c++實現的，如果之前沒有接觸過設計模式，基本上是別想看懂這本書。

不建議作為入門書籍，你可以把其他幾本書看完了，再回頭看這本書。這本書對每種設計模式做了非常精煉的描述，本書的精華在第一章，對面向對象設計領域做了很多高屋建瓴的指導意見，值得一讀。《研磨設計模式》算是對本書的詳細解讀，如果把前者看懂了，這本書基本上不需要看。

6.《設計模式沉思錄》，推薦指數：??????

這本書是GOF作者之一寫的，主要對於設計模式存在的一些誤區做了解釋，然後給出了一些使用設計模式的知道意見。可以了解下。

7. 《Objective-C編程之道:IOS設計模式解析》，推薦指數：??

爛書一本！！

首先翻譯就是稀爛，語句不通，不知道寫的什麼玩意。其次這本書雖然是針對iOS寫的，但是根本就沒有針對iOS這個特定的領域來講解設計模式，掛羊頭賣狗肉，舉得例子根本沒實用性，除了少數幾個還算有點用。

更奇葩的是，很多地方都是強行使用設計模式，把本來簡單的實現改非常復雜，吃飽的撐得。設計模式是解決問題的，不是制造問題的。

反正爛書一本，不推薦看。

如何看書

吐槽完了，說下我的學習建議：

高階：只看一本《研磨設計模式》足矣，把這本書反反復復的搞透，其他基本不用看了。

中階：《head first設計模式》------->《研磨設計模式》

初階：《大話設計模式》----> 《head first設計模式》---->《研磨設計模式》

書看完了，只是知道了有這麼個玩意存在，如何靈活運用，就需要看開源項目區領悟這些設計模式的妙處和精髓了，你會看到設計模式在各種開源項目框架中存在，有的是直接使用，有的是變形使用。

多看，多寫，多思考。

設計模式的分類

下面我們就來對設計模式做一個感性的認識吧。

每種設計模式的簡要描述：

GOF的23種設計模式如下圖所示：

如圖所示，設計模式分為目的和范圍兩個維度。

根據目的，我們可以把模型分為三類：創建型，結構型，行為型

根據范圍，可以分為對象和類兩個大類。

具體描述如下，摘自《設計模式》一書

設計模式之間的關聯：

面向對象設計原則SOLID

SOLID原則是為了寫出可復用、可擴展、高內聚、低耦合的代碼。

原則只是戰略層面的指導，沒有代碼能完全遵守著五大原則，要根據實際情況合理取捨。

下面我們來看看SOLID的具體描述：

1、單一職責

一個類只做一種類型責任，當這個類需要承當其他類型的責任的時候，就需要分解這個類。不過在現實開發中，這個原則是最不可能遵守的，因為每個人對一個類的哪些功能算是同一類型的職責判斷都不相同。

2、開放封閉原則

軟件實體應該是可擴展，而不可修改的。也就是說，你寫完一個類，要想添加功能，不能修改原有類，而是想辦法擴展該類。有多種設計模式可以達到這一要求。

3、裡氏替換原則

當一個子類的實例應該能夠替換任何其超類的實例時，它們之間才具有is-A關系。也就是說接口或父類出現的地方，實現接口的類或子類可以代入，這主要依賴於多態和繼承。

4、 接口分離原則

不能強迫用戶去依賴那些他們不使用的接口。換句話說，使用多個專門的接口比使用單一的總接口總要好。 不要提供一個大的接口包括所有功能，應該根據功能把這些接口分割，減少依賴。

5、依賴倒置原則

1. 高層模塊不應該依賴於低層模塊，二者都應該依賴於抽象 

2. 抽象不應該依賴於細節，細節應該依賴於抽象

上面說的五種原則非常之抽象，也是面向對象設計的時候的指導原則，我們只有盡量遵守這些原則，才可以設計出漂亮的代碼。

設計模式就是對這些抽象思想的具體實現，理解每個設計模式，可以加深對這些原則的理解，對我們內功提升大有裨益。

我們在寫代碼的時候最痛苦的莫過於改需求，因為每次改需求，都會導致代碼的大改動，所以我們應該把經常變動的地方封裝起來，讓這些地方的變動不影響其他地方。這就是設計模式的主要作用。

下面我們看看每種設計模式封裝的變化部分：

總結

最後想說的一點是，學了設計模式，也不要不管什麼場合都要硬套上設計模式，才顯得有逼格。如果你寫代碼的時候覺得不需要使用設計模式，那就說明用不上設計模式，等代碼重構的時候，需要用到設計模式才去用，如果你只是私下練練手那沒關系。

學習設計模式是一個漫長的過程，看完書了解每個設計模式的使用才剛剛開始，接下來需要你反復思考、錘煉，把學到這些模式內化為思想，體現到代碼上。

路漫漫其修遠兮。

後面我會寫一系列設計模式的文字，爭取把每個模式講清楚，有什麼錯誤，歡迎指正探討。