IT圈一直有輪迴，一開始說某某某東西非常好，似乎出現了救世主，依靠它能解決一切問題，再過段時間，用的人多了，就慢慢出現異樣的聲音，再過段時間很多人就開始提出反對的口號，甚至全盤否定。設計模式就是這麼一個概念。
十多年前，國內的軟件開發還處於粗獷式的野蠻發展階段，各種碼農寫各自的代碼，碼農之間經常看不懂對方在寫什麼東西，同時又互相輕視對方的代碼水平。直到有一天，不知哪冒出來設計模式這一術語，頓時天亮了，各種碼農，不管有事沒事，不管有懂沒懂，都開始啃Gof的書，開口閉口設計模式，一時間成爲一種高大上的流行，你要不會寫過抽象工廠，你都不好意思和人說自己是碼農。風水輪流轉，現在設計模式沒之前那麼火了，甚至有人開始質疑，並認爲設計模式帶來了太多的流毒。網上流傳甚廣的就是一個hello world的例子，簡簡單單的一行代碼，被設計模式強姦的體無完膚，先後用到抽象工廠，單例模式，觀察者模式，最終輸出了hello world。這個笑話現實中也有很多人在寫。
設計模式是從通用的代碼方案中提煉出來，形成一種可以複用的經驗，並不是說它是最好的，但如果場景恰當，就像套模板一樣使用，並且大多數情況下都不是最壞的方案。但這裏的問題就是何爲場景恰當。有人認爲這裏該使用策略模式，有人認爲該使用代理模式，這種情況下，誰是老闆誰說的就是對的，不要去爭執。
使用設計模式，或者說使用這些經驗能讓代碼更靈活，它封裝了部分變化模式，降低了耦合，並且能很好的擴展和複用，當需求變化時，採用合理的設計模式使得代碼改動非常小。但是問題來了，需求怎麼變，是難以預知的，產品經理並不會因爲你使用了這個設計模式，而去迎合你規定的變法。產品經理定出來的變化千奇百怪，防不勝防，這時候即使你精通各種設計模式，也無法做出良好的設計。（這一切不能全怪碼農，而應該怪產品狗。很多軟件產品，還不需要驚動設計模式這種高大上的武器）。這也是很多人提出避免過度設計的一個理由，因爲很多設計都是徒勞，但是如果碼農非常熟悉行業領域，能夠預判哪裏會出現變化，那倒是可以賭一把，也許套對了模板之後，很多事情做起來就方便多了。
設計模式是爲了彌補醜陋的語言。 很多主流語言，都內置了設計模式，在不知不覺中已經使用到了。正如網上的一個文檔，
http://cdn.oreillystatic.com/en/assets/1/event/12/_The%20Lack%20of_%20Design%20Patterns%20in%20Python%20Presentation.pdf裏面有句話This pattern is invisible in languages with first-class functions（摘自維基百科），意思就是函數式語言中很多設計模式被隱藏了。（first-class functions是指語言將函數視作一等公民）。
觀察者模式——當一個對象變化時，觀察到這種變化的對象，也能做出一些變化。在C#中的delegate/event很好的解決了這種問題。
單例模式——不用再去糾結什麼雙重檢測之類的問題了，在C#直接使用靜態變量，在Java中是用枚舉類型。
簡單工廠模式——通過傳遞泛型類型，在C#中直接使用 Activator.CreateInstance();Java中也有類似用法。
裝飾模式——動態的給一個對象加上額外的功能。C#中使用屬性標籤就可以完美解決。
策略模式——C#中是用delegate，能更簡單的封裝策略。
迭代器模式——C#和Java中完美的支持。
還有很多模式，可能我這輩子都用不上，比如那個抽象工廠模式，一直沒遇到需要用這個東西的地方，還有命令模式，享元模式，也從未用到過。但這並不影響我寫代碼，沒有這些模式的羈絆，代碼寫的也很順暢。（也許確實水平有限，還未能正確的套模板）。
胡適說的對，多研究些問題，少談些主義。多解決些問題，少談些模式。