設計模式一直飽受爭議，很多人對設計模式推崇備至，但也有很多人認為設計模式誤導了編程者，見（《解密“設計模式”》）。
我也只是一個普通的編程人員，這里只能談一談我在學習設計模式中的一些想法，不一定正確，歡迎大家談論。我對設計模式的理解是分階段的：
一、這是些什么亂七八糟的東西？那時候聽到了設計模式的概念，到圖書館借了一本大概名字叫《設計模式初學者入門》之類的書。書里就把23個設計模式挨個講了一遍，引用一下每個設計模式的定義，給個類圖，配點代碼……然后我硬着頭皮讀完之后，就一個感覺，“脫了褲子放屁”。一個功能，明明很簡單、很直接的就能實現，為什么要添那么多的類，繞那么多的彎？記得當時也就懂了“單例模式”。
二、后來又找其他的書，這時候我讀到了程傑的《大話設計模式》，其中用活字印刷的例子，講解了曹操“對酒當歌，人生幾何”的敢動，我仿佛一下子就開竅了。明白了設計模式，他最重要的目的就是為了應對“變化”。所以回過頭來看，為什么之前能懂“單例模式”，就因為“單例模式”的目標很清晰，所以很好懂；反之，其他的設計模式，目標比較“復雜”，所以我懂不了。
三、但僅僅知道了設計模式的目標，還是沒有解決我的疑惑。我記得當時我心里反反復復的一個問題，“有變化，改代碼就行了呀。怎么改都是改，為什么就一定要想你（設計模式）說的那樣改呢？”那時候我基本上是單兵作戰，代碼是自己一個人從頭寫到腳，哪里有問題我就可以改哪里，完全沒有心理負擔，呵呵。后來工作變動，開始了團隊開發、維護別人的代碼，以及使用第三方組建。我就自然而然的明白了，有些代碼，是你只能用不能改的！典型的就是人家只給你一個已經編譯的dll，你怎么改？坑爹呀！所以，那時候，我最先明白的就是Adapter模式，為什么要用Adapter？因為接口不一致，你不使用Adapter就用不了第三方的代碼！
四、如果說上面這個階段是“迫不得已”的使用設計模式，接下來就是我開始主動的思考和使用設計模式了。我有差不多一年的時間都是在維護公司遺留下來的老代碼——足以讓人崩潰的代碼！每一次的bug fix，都不得不小心翼翼、如履薄冰，即使如此，仍然有很多次的改動，都是“按下了葫蘆浮起了瓢”。讓我充分的意識到什么叫“緊耦合”、“壞味道”，我們會有計划的做一些重構，在這些過程中，我都會主動的思考，能不能套用某種設計模式（但沒有一次成功，老大不讓，擔不起責任呀——系統太老太大太脆弱，你懂的！呵呵）
五、真正的理解設計模式的核心思想。我認為我目前仍然沒有達到這個程度，雖然可以隨口說出一些耳熟能詳的設計原則，“高內聚、低耦合”，“對擴展開放，對修改關閉”，“優先使用聚合”之類的。但理解仍然不深，很多時候覺得這也可那也可，拿不定主意。我覺得這是我代碼寫得太少的原因，需要在更多的實踐中體會提高。
看完這些，你肯定知道，我對學習設計模式是持支持肯定態度的。那么，下面和同學們交流一下學習設計模式的方法吧。
一、實踐。記得金旭亮老師曾經說過，“沒有寫過10萬行代碼，不要談設計模式”，可能有點誇張，但道理是棒棒的。比如我，如果沒有不得不深入到那些足夠復雜足夠混亂的代碼，身心飽受摧殘，不可能對設計模式的認識有質的提高。因為設計模式的一個重要應用場景，是應付那些復雜的業務邏輯、快速的需求變化，她的價值在這些地方，才能夠清晰的體現出來。“坐而論道”是一種我們都期望的“懶人模式”，但估計很難有效——至少對於我這種資質平庸的人來說吧。
二、明白設計模式的目的。每一個設計模式，一定是要解決一定的問題的；並且解決這些問題是附帶了條件的。比如，需求發生了變更，這是問題。如果沒有其他約束，解決這個問題的辦法很簡單，就是改代碼而已，加上一個if...else而已。但是，我們不能這些改！（理解這一點相當重要，切記切記。當然，你可能會問，為什么不能這么改呢？我們下面再說）我們不能修改類里面的代碼，我們只能采取一些其他手段，比如繼承、比如封裝原有類，來實現新需求。這時候，設計模式就粉墨登場了。
三、上面所說，為什么不能直接改類里面的方法函數，比如直接加if...else？我們可以從兩方面理解。一方面是“被動的”，比如我們是引用的一個編譯了的dll，根本就改不了；或者是團隊開發，別人不允許你改他們寫好的類。另一方面是“主動的”，接前面“團隊開發，別人不允許你改他們寫好的類”，為什么他們不允許你改呢？是不是他們固執、偷懶，沒有團隊精神？你把官司打到大BOSS那里，可能會被一頓K。你需要仔細的體會，“類”的概念。類就是一種封裝，封裝就意味着拒絕修改——想一想為什么會有private關鍵字吧。好了，就不在這里展開了，不然又要寫一本書了。你只需首先明白，設計模式，是一種“帶着腳鐐的舞蹈”；然后進一步思考，為什么需要這些腳鐐即可。（當然，如果你夠牛B，這些最終砸碎這些腳鐐，不在此探討范疇）
最后，我還是強調“實踐”，如果想要更好的理解第二條、第三條，唯一有效的方法，可能就是實踐了（前提是你已經或多或少的研究過設計模式了）。