設計模式系列1--開篇漫談

大概花了一個半月的時間把市面上比較知名的設計模式類的書所有買回來學習了一遍，這些書裏面有好有壞。
若是想系統的學習設計模式，我建議仍是買書看，由於書上的知識比較系統和權威，不像網上的文章參差不齊，雖然有不少有些的博客的文章不錯，可是剛開始自學也沒有能力去分辨。

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

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

---

什麼是設計模式

定義：

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

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

一、軟件開發：
其實各行各業都有模式能夠套用，這裏的設計模式指的是在軟件開發領域

二、通過驗證的：
必須是通過你們公認和驗證過的解決方案纔算得上是設計模式，而不是每一個人隨便總結的解決方案都能算

三、特定環境：
必須是在某個特定環境纔可使用該設計模式，由於不一樣的環境，就算一樣的問題，解決方案也不一樣，因此不能脫離環境去談使用設計模式

四、重複出現：
由於只有重複出現的問題纔有必要總結經驗，造成固定的解決方案，再次遇到這樣的問題就不用從頭開始尋找解決方案，而是直接套用就能夠了。

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

每一個設計模式的構成以下：

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

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

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

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

---

爲何要學習設計模式

引用知乎上面的一段話：

image

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

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

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

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

經過學習這些設計模式，讓你找到「封裝變化」、「鬆耦合」、「針對接口編程」的感受，從而設計出易維護、易複用、擴展性好、靈活性足的程序。

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

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

學完設計模式只是第一步，並不會讓你的編碼水平有了質的飛躍，接下來須要你經過大量實踐來消化這些設計模式的精髓，內化爲本身的思想，從而體如今代碼上。

---

如何學習設計模式

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

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

image

2.如何學習設計模式

image

---

學習建議

若是你看完上面的內容，以爲頗有必要學習設計模式來提升本身的內功，那麼能夠接着看下去。

個人學習建議以下，也是對這幾本書的評價吧，你們能夠作個參考

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設計模式》---->《研磨設計模式》

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

多看，多寫，多思考。

---

設計模式的分類

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

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

image

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

image

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

根據目的，咱們能夠把模型分爲三類：建立型，結構型，行爲型

根據範圍，能夠分爲對象和類兩個大類。

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

image

設計模式之間的關聯：

image

---

面向對象設計原則SOLID

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

原則只是戰略層面的指導，沒有代碼能徹底遵照着五大原則，要根據實際狀況合理取捨。

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

image

一、單一職責

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

二、開放封閉原則

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

三、里氏替換原則

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

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

五、依賴倒置原則

1. 高層模塊不該該依賴於低層模塊，兩者都應該依賴於抽象
2. 抽象不該該依賴於細節，細節應該依賴於抽象

上面說的五種原則很是之抽象，也是面向對象設計的時候的指導原則，咱們只有儘可能遵照這些原則，才能夠設計出漂亮的代碼。

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

咱們在寫代碼的時候最痛苦的莫過於改需求，由於每次改需求，都會致使代碼的大改動，因此咱們應該把常常變更的地方封裝起來，讓這些地方的變更不影響其餘地方。這就是設計模式的主要做用。

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

image

---

總結

最後想說的一點是，學了設計模式，也不要無論什麼場合都要硬套上設計模式，才顯得有逼格。若是你寫代碼的時候以爲不須要使用設計模式，那就說明用不上設計模式，等代碼重構的時候，須要用到設計模式纔去用，若是你只是私下練練手那不要緊。

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

路漫漫其修遠兮。

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