設計模式不是一般的難！
第一難：需要你有真正的OO水平，有大量的編碼及設計基礎。
第二難：難以在工作中真正實踐全部23中設計模式，無實踐就無法真正理解。很少系統需要用到設計模式，或者只能用到很少的一部分。我們這些軟體開發人員，大部分都是在做資料庫的CRUD的工作，設計模式難有用武之地。
第三難：學習資料要麼太深奧難懂，要麼就是太膚淺了。
第四難：你以為你懂了，其實你沒懂！設計模式學習過程是迂迴前進的。
第五難：找不到高手與你溝通！
超級掃盲 - 什麼是設計模式？
什麼是設計模式？
設計模式，英文名字叫Design Pattern，這個“Pattern”硬生生地給翻譯成“模式”，徒增了很多人的理解難度。
話說回來，我也不知道咋翻譯好，反正設計模式這個說法說得多了，也就習慣了。
設計模式就是一些軟體設計高手總結後得出的一些設計經驗總結，目前還沒有習慣設計模式這個說法的朋友就暫時不要去考究這個名字了，大概知道它的意思便可。
有什麼設計模式？
設計模式一共有23種，按以下分類：
建立型（5種）
1) 工廠方法(Factory Method)
2) 抽象工廠(Abstract Factory)
3) 單件(Singleton)
4) 生成器(Builder)
5) 原型(Prototype)
結構型（7種）
1) 裝飾者(Decorator)
2) 介面卡(Adapter)
3) 外觀(Facade)
4) 組合(Composite)
5) 代理(Proxy)
6) 橋接(Build)
7) 輕量(Flyweight)
行為型（11種）
1) 策略(Strategy)
2) 觀察者(Observer)
3) 命令(Command)
4) 模板方法(Template Method)
5) 迭代器(Iterator)
6) 狀態(State)
7) 責任鏈(Chain)
8) 直譯器(Interpreter)
9) 中介者(Mediator)
10) 備忘錄(Memo)
11) 訪問者(Visitor)
以上分類是按“官方”標準進行劃分的，所謂的“官方”就是軟體設計屆的4位骨灰級人物：Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides，這幾位作者常被稱為"四人組（Gang of Four，縮寫為GoF）"，他們的著作就是《Design Patterns: Elements of Reusable Object-Oriented Software》（中文名：《設計模式 可複用物件導向軟體的基礎》）。
關於設計模式的吐槽
慘不忍睹的軟體設計現狀與設計模式的理想境界
許多年前，IT行業是被崇拜的行業，程式設計師更是神聖的職業。但現在早已是程式設計師氾濫，大量的計算機專業應屆生湧入程式設計的行列，蛇龍混雜，參差不齊。很多隻在學校學過一兩門程式設計，所寫的程式碼行數不超過1000行的人，就直奔程式設計來了！編碼功底不過關的程式設計師比比皆是，更甚者直奔軟體設計去了。
國產的大部分軟體，無設計可言，90%以上的專案是沒有設計文件的，絕大部分的專案程式碼是沒有人願意去動的，大部分的專案經理做專案都是抱著早做完早解脫的心態，大部分的軟體設計師沒有感受到軟體設計的魅力，沒有辦法去享受軟體設計的樂趣。
設計模式能拯救我們這樣的現狀嗎？設計模式為我們勾畫了軟體設計的美好境界，讓我們很多人趨之若騖，很多人想在實際工作中運用設計模式，當往往是碰一鼻子灰，這有很多原因：
1) 我們的水平還不夠，沒有能真正理解好設計模式，自然無法用好。
2) 我們絕大部分的系統是資料庫增刪改查的四輪馬車操作，設計模式的用武之地很小。
然而更深層次的原因是：
1) 國內的軟體程式設計及設計的教育實在太差，計算機相關專業知識陳舊落後。
2) 國內軟體水平實在落後，絕大部分軟體企業是做解決方案、外包等應用級別的開發，精品軟體、劃時代的軟體、改變世界的軟體幾乎等於零。
3) 國家在軟體行業的方針路線有誤，重點應該是打造核心技術和培養高階人才，不要去折騰什麼外包、CMMI，核心技術和高階人才才是國家核心競爭力。
設計模式不是紙上談兵
n年前，我就買了GoF大作《Design Patterns: Elements of Reusable Object-Oriented Software》（中文版），不過實在慚愧，當時水平太差，裡面的內容大部分是似懂非懂。儘管我已經寫了幾年程式碼，但功力依然是不足，經驗也不夠多，但大師的知識一時難以吃透。再過了幾年，我又再次研究設計模式，這次居然基本可以看懂那本書了，感覺特妙！
設計模式絕對不是紙上談兵的知識，光看書就以為自己懂了，那只是井底之蛙之見，設計模式絕對是從實踐中來到實踐中去的！如果編碼經驗很少，也不太可能能理解好設計模式，但凡軟體設計能力強的人編碼功底都是相當紮實的。如果沒有能深刻理解物件導向，也不太可能理解好設計模式。
高手是怎樣煉成的？
我不是設計模式的高手，但我希望成為高手，要達成這個目標，還需要多年的努力。
按對設計模式的熟悉程度，我劃分了以下幾種檔次：
1. 不知道：沒聽說過，或者只知道名字。
2. 能說：能簡單說出該模式的用途。
3. 能畫：能準確地畫出該模式的類圖，或者畫出實際應用的類圖。
4. 能寫：能寫出實現該模式的例項程式碼。
5. 會用：能在實際工作中用起來。
6. 活用：很熟練，能在工作中創造性地應用設計模式，可以指導別人應用設計模式工作。
對於我來說，23種模式我大概只能達到第3到第4的層次，如果能達到第6個層次，那簡直就是世外高人了！
如何學習設計模式？
說說我的一些學習體會：
1. 要用真正物件導向的語言來程式設計，如Java、C#、C++，這樣才能加速你對物件導向、設計模式的理解。
我最開始用的程式語言是Basic，然後是Visual Basic，結果抽象類、繼承這些東西基本上沒有能在實際工作中體會過，後來用C#後才算是真正體會到物件導向。
2. 找顯淺的設計模式書來學習。
GoF的經典大作好是好，但很難看懂，後來我看了比較顯淺的《Head First 設計模式》，終於我讓跨進了實質的一步。
3. 在實際工作中多用類圖。
類圖光會看是遠遠不夠的，要多多實踐，通過類圖來提高你的OO能力！
4. 多想具體的應用例子，並寫出示例程式碼。
儘管有一些顯淺的設計模式書，但裡面不少例子沒有實際的應用價值，有些書甚至還會用一些實際生活中的例子來說明某某模式，我覺得有點牽強附會。書中的大部分例子，只能幫助你大概理解該模式，更重要的是你必須想到在實際工作中的具體應用，寫出具體的程式碼來。當然要做到這點很難，需要有很多工作經歷。
5. 多提問題，敢於挑戰傳統想法。
學習過程中，一定要多多思考、深入思考，多提問題，你會發現有些問題與你之前的認識是相左的，有些問題是和別人的看法是矛盾的，有時你甚至會去懷疑GoF是不是搞錯了，這些都很正常，也是很好的事情。
設計模式的難度及有用程度
以下兩個表是我的個人體會，僅供參考。
按理解難度分類
按有用程度分類
請看下一文……
作者：張傳波
創新工場創業課堂（敏捷課程）講師
軟體研發管理資深顧問
CMMI首席專家
《火球——UML大戰需求分析》作者