一直都對設計模式有一種膜拜之情，覺得設計模式是一種高深的技術，一年前大致看了一遍23種設計模式覺得就是一些固定調用，繼承，派生的方式，以爲記住就可以了。而對設計原則和設計思想視而不見。
再經過了一年的學習和項目經驗後在來重新學習設計模式，發現自己有了一些新的思考：
1、 設計模式是思想，不是固定套路。是爲了更好地讓代碼適應變化。
2、 設計模式是爲了應對局部變化而產生的。如果程序沒有變化，那麼就不需要設計模式，如果程序到處都在變化，那麼也不需要設計模式，因爲設計模式的核心思想就是把不變的“趕”到一起，把變化的“趕”到一起，當需求變化的時候，就只需要集中修改“變”那一部分，從而減少需要修改的範圍，當需求變化時，提高軟件適應性。
筆者自己學習設計模式的幾個誤區：
1、 設計模式用好了，代碼就不需要改了。這是我當時天真的認識，現在看來其實是極其荒謬的。如果需求改變沒有導致代碼的變化，那麼這就不算需求變化。可以說當需求改變，代碼一定是要改變（增加、刪除、修改）的。
2、 拿到需求就考慮該用什麼設計模式。這也是一個誤區，拿到需求，根本就沒有變化，是不需要設計模式的，這純粹是一種“爲賦新詞強說愁”。不爲變化而設計的設計模式都是耍流氓。
3、 我能一來就想到最好的設計模式。現在我認爲這也是不對，設計模式在代碼中的使用也應該是一個迭代改進的過程，是在寫代碼的過程中感覺到了不爽，然後進行修改，提取而得到的結果。
在後面的的文章中，筆者將就集中常用的設計模式用儘可能直白的語言進行論述，並分析經典的案例，看看那些經典的代碼，框架是怎麼把這些變化趕到一起去的。