前言

為什么寫這本書

2009年5月份，我在JavaEye上發了一個帖子，其中提到自己已經工作9年了，總覺得這9年不應該就這么荒廢了，應該給自己這9年的工作寫一個總結，總結的初稿就是這本書。

在談為什么寫這本書之前，先抖抖自己前9年的職業生涯吧。大學時我是學習機械的，當時計算機剛剛熱起來，自己也喜歡玩一些新奇的東西，記得最清楚的是用VB寫了一個自由落體的小程序，模擬小球從桌面掉到地板上，然后計算反彈趨勢，很有成就感。于是2000年畢業時，我削尖了腦袋進入了IT行業，成為了一名真正的IT男，干著起得比雞早、睡得比狗晚的程序員工作，IT男的辛酸有誰知曉！

坦白地說，我的性格比較沉悶，屬于典型的程序員型悶騷，比較適合做技術研究。在這9年里，項目管理做過，系統分析做過，小兵當過，團隊領導人也當過，但至今還是一個做技術的。要總結這9年技術生涯，總得寫點什么吧，最好是還能對其他人有點兒用的。那寫什么好呢？Spring、Struts等工具框架類的書太多太多，很難再寫出花樣來，經過一番思考，最后選擇了一個每一位技術人員都需要掌握的、但普及程度還不是非常高的、又稍微有點難度的主題——設計模式（Design Pattern，DP）。

中國人有不破不立的思維，遠的如秦始皇焚書坑儒、項羽火燒阿房宮，近的如破“四舊”。正是由于有了這樣的思想，于是乎能改的就改，不能改的就推翻重寫，沒有一個持續開發藍圖。為什么要破才能立呢？為什么不能持續地發展？你說這是誰的錯呢？是你架構師的錯，你不能持續地擁抱變化，這是一個系統最失敗的地方。那怎么才能實現擁抱變化的理想呢？設計模式！

設計模式是什么？它是一套理論，由軟件界的先輩們（The Gang of Four：包括Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides）總結出的一套可以反復使用的經驗，它可以提高代碼的可重用性，增強系統的可維護性，以及解決一系列的復雜問題。做軟件的人都知道需求是最難把握的，我們可以分析現有的需求，預測可能發生的變更，但是我們不能控制需求的變更。問題來了，既然需求的變更是不可控的，那如何擁抱變化呢？幸運的是，設計模式給了我們指導，專家們首先提出了6大設計原則，但這6大設計原則僅僅是一系列“口號”，真正付諸實施還需要有詳盡的指導方法，于是23種設計模式出現了。

設計模式已經誕近20年了，其間出版了很多關于它的經典著作，相信大家都能如數家珍。盡管有這么多書，工作5年了還不知道什么是策略模式、狀態模式、責任鏈模式的程序員大有人在。不信？你找個機會去“虛心”地請教一下你的同事，看看他對設計模式有多少了解。不要告訴我要翻書才明白！設計模式不是工具，它是軟件開發的哲學，它能指導你如何去設計一個優秀的架構、編寫一段健壯的代碼、解決一個復雜的需求。

因為它是軟件行業的經驗總結，因此它具有更廣泛的適應性，不管你使用什么編程語言，不管你遇到什么業務類型，設計模式都可以自由地“侵入”。

因為它不是工具，所以它沒有一個可以具體測量的標尺，完全以你自己的理解為準，你認為自己多了解它，你就有可能產生多少的優秀代碼和設計。

因為它是指導思想，你可以在此基礎上自由發揮，甚至是自己設計出一套設計模式。

世界上最難的事有兩件：一是讓人心甘情愿地把錢掏出來給你，二是把自己的思想灌輸到別人的腦子里。設計模式就屬于第二種，它不是一種具體的技術，不像Struts、Spring、Hibernate等框架。一個工具用久了可以熟能生巧，就像砌墻的工人一樣，長年累月地砌墻，他也知道如何把墻砌整齊，如何多快好省地干活，這是一個人的本能。我們把Struts用得很溜，把Spring用得很順手，這非常好，但這只是一個合格的程序員應該具備的基本能力！于是我們被冠以代碼工人（Code Worker）——軟件行業的體力勞動者。

如果你通曉了這23種設計模式就不同了，你可以站在一個更高的層次去賞析程序代碼、軟件設計、架構，完成從代碼工人到架構師的蛻變。注意，我說的是“通曉”，別告訴我你把23種設計模式的含義、適應性、優缺點都搞清楚了就是通曉。錯了！沒有工作經驗的積累是不可能真正理解設計模式的，這就像大家小時候一直不明白為什么爸爸媽媽要工作而不能每天陪自己玩一樣。

據說有的大學已經開了設計模式這門課，如果僅僅是幾堂課，讓學生對設計模式有一個初步的了解，我覺得并無不妥，但如果是專門的一門課程，我建議取消它！因為對一個尚無項目開發經驗的學生來說，理解設計模式不是一般困難，而是非常非常困難！之前沒有任何的實戰經驗，之后也沒有可以立即付諸實踐的場景，這樣能理解設計模式嗎？

在編寫本書之前，23種設計模式我都用過，而且還算比較熟練，但是當真正要寫到書中時，感覺心里沒譜兒了。這個定義是這樣的嗎？是需要用抽象類還是應該用接口？為什么在這里不能抽取抽象呢？為什么在實際項目中這個模式要如此蛻化？這類小問題有時候很糾結，需要花費大量的精力和時間去分析和確認。所以，在寫作的過程中我有過很多憂慮，擔心書中會有太多瑕疵，這種憂慮現在仍然存在。遇到挫折的時候也氣餒過，但是我堅信一句話：“開弓沒有回頭箭，回頭即是空”，既然已經開始，就一定要圓滿完成。

第2版與第1版的區別

本書是第2版，在寫作中吸取了讀者對上一版的許多意見和建議，修訂了一些代碼的變量、類、方法名稱，以更加符合自然語言；刪除了部分有爭議的內容（如單例模式的垃圾回收問題）；修改了一些常用的名詞，確保與編程人員的習慣相匹配。希望通過這些改進，給讀者提供一個更完美的設計模式盛宴，彌補上一版中的諸多不足。

第2版第38章中新增了4種新的設計模式：對象池模式、雇工模式、黑板模式、空指針模式。這些模式是我們在實際工作中經常遇到，或者在開源代碼時常看到的，但是我們卻沒有升級到“模式”這一理性高度。特別是像空指針模式，我們在編碼中經常會遇到空值判斷問題，但我們沒有去想一想是否可以有更好的方式解決。第2版對空指針模式進行了講解，雖然簡單，但相信對你提升編碼質量有很大的幫助。

本書的特色

簡單、通俗、易懂，但又不膚淺，這是本書的最大特色。自己看過的技術書還算比較多，很痛恨那種大塊頭的巨著，擱家里當枕頭都覺得太硬。如果要是再晦澀難懂點，那根本沒法看，看起來實在是太累。設計模式原本就是理論性的知識，講解的難度比較大，但我相信這本書能夠把你對設計模式的恐懼一掃而光。不信？挑幾頁先看看！

我的理念是：像看小說一樣閱讀本書。我盡量用淺顯通俗的語言講解，盡量讓你有繼續看下去的欲望，盡量努力讓你有興趣進入設計模式的世界，興趣是第一老師嘛！雖然我盡量讓這本書淺顯、通俗、易懂，但并不代表我的講解就很膚淺。每個設計模式講解完畢之后，我都附加了兩個非常精華的部分：設計模式擴展和最佳實踐，這是俺壓箱底的技能了，為了博君一看，沒招了，抖出來吧！尤為值得一提的是，本書還有設計模式PK和混編設計模式兩部分內容教你如何自如地去運用這些設計模式，這是當前所有設計模式類的圖書都不具備的，連最權威的那本書也不例外。

我很討厭技術文章中夾雜著的那些晦澀難懂的文字，特別是一堆又一堆的名詞堆砌，讓人看著就反胃。但是為了學習技術，為了生存，還是必須看下去。國內的技術文檔，基本上都是板著一副冷面孔講技術，為什么要把技術弄得這么生硬呢？技術也有它幽默、柔情的一面，只是被我們的“孔夫子們”掩蓋了，能用蘿卜、白菜這種尋常人都熟悉的知識來講解原子彈理論的人，那是牛人，我佩服這樣的人。記住，用一堆名詞把你忽悠暈的人很可能什么都不懂！

本書想告訴你的是，技術也可以很有樂趣，也可以讓你不用皺著眉頭思考，等待你的只是靜靜地看，慢慢地思考，本書的內容會潤物細無聲地融入你的思維中。

本書面向的讀者

熱愛技術并且討厭枯燥乏味技術文章的讀者都可以看本書；

你是程序員，沒問題，本書能夠讓你寫出更加高效、優雅的代碼；

你是架構師，那更好，設計模式可讓你設計出健壯、穩定、高效的系統，并且自動地預防未來業務變化可能對系統帶來的影響；

你是項目經理，也OK，設計模式可以讓你的工期大大縮短，讓你的項目團隊成員快速地理解你的意圖，最終的成果就是優質的項目：高可靠性、高穩定性、高效率和低維護成本。

如何閱讀本書

首先聲明，本書中所有的例子都是用Java語言來實現的，但是你可以隨手翻翻看，基本上能保證每三條語句一個注釋，可以說是在用咱們的母語講解設計模式。即使你不懂Java語言，也沒有關系，只要知道在Java中雙斜杠（//）代表注釋就足夠了，況且Java如此強大和盛行，多了解一點沒有壞處。類圖看不懂？沒關系，不影響你理解設計模式，多看看就懂了！

如果你還沒有編程經驗，我建議你把它當做小說來看，懂行的看門道，不懂行的看熱鬧，這里的熱鬧足夠多，夠你看一壺的了。你現在能看懂多少是多少，不懂沒有關系，你要知道，經驗不是像長青春痘一樣，說長就長出來了，它是需要時間積累的，需要你用心去感受，然后才能明白為什么要如此設計。

如果你已經對編程有感覺了（至少兩年開發經驗），我相信你都能看懂，但能“懂”到什么程度，就很難說了，看你的水平了。但是，我可以保證，這里的設計模式都是你能看懂的，沒有你看不懂的！我建議你通讀這本書，然后挑門你最得意的編程語言，動手寫吧！給自己制定一個計劃，每天編寫一段代碼，不需要太多，200行足夠，時不時地把設計模式融入你的代碼中。甭管是什么代碼，比如你想編寫一個識別美女圖片的程序，好呀，抓緊時間去寫吧，寫好了就不用到處看美女了，程序一跑就把網上的美女圖片都抓過來了，牛呀（記住，程序寫好了要分享給我）。看吧，堅持下去，一年以后你再跟你的同儕比較一下，那差距肯定不是一般的大。

如果你是資深工程師、架構師、技術顧問等高等級的技術人員，那我告訴你，你找對這本書了。系統架構沒有思路？沒有問題，看看擴展部分，它會開闊你的思路。系統的維護成本居高不下？看看本書，設計模式也許能幫你省點銀子。開發資源無法保證？設計模式能讓你用有限的資源（軟硬件資源和人力資源）設計出一個優秀的系統。項目質量參差不齊，缺陷一大堆？多用設計模式，它會給你意想不到的效果。給人講課沒有素材？沒問題，本書中的素材足以讓你贏得陣陣掌聲！

編程是一門藝術活，我有一個同事，能把類圖畫成一個小烏龜的形狀，天才呀！作為一位技術人員，最基本的品質就是誠實，“知之為知之，不知為不知，是知也”，自己不懂沒有關系，去學，學無止境，但是千萬不要貪多，這抓一點，那挖一點，好像什么都懂，其實什么都不懂。中國一直推崇復合型人才，我不是很贊成，因為這對年輕人來說是一個誤導。先精一項技術，然后再發散學習，先點后面才是正道。

記得《武林外傳》中有這樣一段對話：

刑捕頭：手中無刀，心中有刀。

老白：錯了，最高境界是手中無刀，心中也無刀。

體驗一下吧，我們的設計模式就是一把刀，極致的境界就是心中無設計模式，代碼亦無設計模式——設計模式隨處可見，俯拾皆是，已經融入軟件設計的靈魂中，這才是高手中的高手，簡稱高高手。

哦，最最重要的忘記說了，請把附錄中的“23種設計模式附圖”撕下來，貼在你的辦公桌前，時不時地看看，也讓老板看看，咱是多么地用心！

關于書名

乍一看，書名和內容貌似不相符呀，其實不然！

在我們的常規思維中，“禪”應該是很高深的東西，只可意會，不可言傳。沒錯，禪宗也是如此說。禪是得道者的“悟”，是不能用言語來表達的，但是得道者為了能讓更多的人“悟”，就必須用最容易讓人理解的文字把自己的體會表達出來。本書的“禪”是作者對設計模式的“悟”，本書的“形”就是你現在看到的這些極其簡單、通俗、易懂的文字。

至此，大家應該不會再對書名有疑慮了吧，嘿嘿。

致謝

本書第1版的寫作耗時7個月，第2版的更新又花了4個月，可以說是榨干了海綿里所有的水——基本上能用的時間都用上了。在公交車上打腹稿，干過！在馬桶上查資料，干過！在睡夢中思考案例，也有過！就差沒有走火入魔了！

首先，感謝楊福川編輯，沒有他的慧眼，這本書不可能出版。其次，感謝妻子和兒子，每天下班回到家，一按門鈴，兒子就在里面叫：“我來開門，我來開門。”兒子三歲，太調皮了，他不睡覺我基本上是不能開寫的，我一旦開始寫東西，他就跑過來問：“爸爸，你在干什么呀”，緊接著下一句就是“爸爸，你陪我玩”，基本都是拿我當玩具，別的小朋友都是把父親當馬騎，他卻不，他把我當摩托車騎，還要加油門，發動……小家伙腳太重了，再騎摩托，非被他踩死不可！

還要感謝我的朋友王驄，周末只要小家伙在家，我只有找地方寫書的份兒，王驄非常爽快地把鑰匙給我，讓我有一個安靜的地方寫書。一個人沉浸在自己喜歡的世界里也是一件非常幸福的事。

當然，還要感謝JavaEye上所有頂帖的網友，沒有你們的支持我就沒有寫作的動力，就像希臘神話中的巨人安泰失去了大地的力量一樣，是你們的回帖讓我覺得不孤單，讓我知道我不是一個人在戰斗！

最后，再次對本書中可能出現的錯誤表示歉意，真誠地接受大家轟炸！如果你在閱讀本書時發現錯誤或有問題想討論，請發郵件給我。