一個月下來，把常見的20個設計模式好好複習並且逐個用C++實現了一遍，收穫還是很大的，很多東西看上去明白了但是真正動手去做的時候發現其實還是不明白——我深知這個道理，於是不敢怠慢，不敢寫什麼所謂的解釋原理的僞代碼，不敢說所謂的"知道原理就可以了"……因爲我知道，我還還沒有資格說這個話，至少對於設計模式而言我還是一個初學者，唯有踏實和實幹才能慢慢的掌握到知識。
在我學習設計模式的過程中，覺得造成理解困難的主要是以下幾點，談一下自己的體會，希望對他人有幫助，不要走上我的老路上，畢竟我花了N長的時間纔敢號稱自己入門了~~！！-_-：
1）Gof並不適合於初學者。初學設計模式的一般都是從Gof入門開始學習的，不幸的是，這不是一本好的教科書，而把這本書稱爲一本奠定了設計模式理論基礎的開山之作也許好一些，它把這些散落在各個設計中的常見模式收集起來，從此開始有了一個名詞叫做"Design Pattern".說這本書不是一本好的教科書主要是以下的幾個原因：a）對設計模式或者說面向對象裏面的一些原則性的東西解釋的不夠多不夠徹底，比如"面向接口編程而不是對實現編程"，"優先採用組合而不是繼承"等等，以至於後面看到各個模式的實現的時候很多模式看起來很相似卻找不到區別和共性的地方。 b）對各個模式的解釋或者舉出來的例子不是特別的好，大部分都是爲了講解模式而講解，沒有加入前面提到過的一些基本原則的考量在裏面，也就是說：原理性的東西和實現（各個設計模式）脫節。
2）初學者對語言或者說一些概念理解的不好。拿C++來說，爲了做到面向對象需要提供的語言上的支持有繼承，多態，封裝，虛函數，抽象等等，我以前初學C++的時候，只爲了學這些概念而去學習，不知道爲什麼要提供這些特性，這也是造成我走彎路的重要原因之一。當然，指望一個初學者在初學語言的時候就知道why是一件很困難的事情，也許結合着對設計模式的理解可以幫助你消化這些概念（我就是這樣的）。
3）看不懂UML結構圖和時序圖，UML圖解釋的類與類之間的關係，時序圖解釋的是各個對象的實現方式，兩者結合在一起看才能加深對設計模式的理解，事實上，我現在已經可以做到僅僅看這兩個圖示就掌握一個模式的原理和實現了。
4）寫的代碼和參與過的項目不夠多。設計模式和很多東西的產生過程都是一樣的，首先人們遇到了問題，然後很多人解決了這個問題，於是漸漸的有人出來總結出解決這些問題所要遵守的一些原理和常用方法（我們稱之爲"模式"），久而久之就形成了一個理論或者說一個學科。而後人在講述這些理論的時候大都是照本宣科，這對於計算機這樣一個強調實踐的學科或者說對於設計模式這樣一個理論而言要理解起來是很困難的。前人在提出這些理論的時候一些考量，權衡等等只有在你自己遇到了這些問題的時候才能慢慢的體會。有一種說法是，沒有寫上10W行代碼不要空談什麼設計模式大概就是這個意思吧。
綜上所述，造成初學者學習設計模式困難的原因，一個是對基本的原則理解的不夠透徹，一個的選的入門教材不合理，還有一個就是對各個模式的表述不明白，再次是實踐不夠多。
有幾本書籍，我看過，我想可以談談我的看法。
第一本，<<敏捷軟件開發：原則，模式與實踐>>，這本書對於設計模式最大的貢獻在於專門有幾個章節講述了面向對象的幾個原則，比如Likov原則，開放封閉原則等等的，這幾個章節在我學習設計模式的過程中起了關鍵的作用，因爲當我理解了這些原則之後開始慢慢明白爲什麼要有純虛函數提供接口，爲什麼要有抽象基類，爲什麼要封裝……我開始用這些原則去理解各個設計模式，開始慢慢體會各個模式的區別和共性。
另外看過的兩本書，我覺得性質都一樣，如果你缺錢，任選其一吧。第一本是<<設計模式精解>>，第二本是<<深入淺出設計模式>>，都是我花上幾個晚上就可以看完的書。這兩本的立足點都是以生動的例子結合面向對象的基本原理來講解模式，我更喜歡前者一些（後者太貴，要不是打5折我纔不買吶：）