大話設計模式 pdf epub mobi txt 电子书 下载 2025

☆☆☆☆☆

程傑 著

出版社： 清华大学出版社

ISBN：9787302162063

版次：1

商品编码：10079261

包装：平装

开本：16开

出版时间：2007-12-01

用纸：胶版纸

页数：368

字数：683000

産品特色

編輯推薦

　　

　　《大話設計模式》是準備攀登麵嚮對象編程高峰朋友們的引路人和提攜者；《大話設計模式》是學習、體會和領悟瞭眾多大師智慧結晶後的圖書作品；《大話設計模式》是你深入理解和感受GoF的《設計模式》及其它大師作品的必備書籍；《大話設計模式》授之以“魚”，更授之以“漁”。　　
　　感受設計演變過程中所蘊含的大智慧，體會樂與怒的程序人生中值得迴味的一幕幕。
　　設計模式的趣味解讀，麵嚮對象的深入剖析。
　　在詼諧與溫馨中做一次麵嚮對象編程思維的體操。

內容簡介

　　本書通篇都是以情景對話的形式，用多個小故事或編程示例來組織講解GoF（設計模式的經典名著——Design Patterns：Elements of Reusable Object-Oriented Software，中譯本名為《設計模式——可復用麵嚮對象軟件的基礎》的四位作者Erich Gamma、Richard Helm、Ralph Johnson，以及John Vlissides，這四人常被稱為Gang of Four，即四人組，簡稱GoF）總結的23個設計模式。本書共分為29章。其中，第1、3、4、5章著重講解瞭麵嚮對象的意義、好處以及幾個重要的設計原則；第2章，以及第6到第28章詳細講解瞭23個設計模式；第29章是對設計模式的全麵總結。附錄部分是通過一個例子的演變為初學者介紹瞭麵嚮對象的基本概念。本書的特色是通過小菜與大鳥的趣味問答，在講解程序的不斷重構和演變過程中，把設計模式的學習門檻降低，讓初學者可以更加容易地理解——為什麼這樣設計纔是好的？是怎樣想到這樣設計的？以達到不但授之以“魚”，還授之以“漁”的目的。引導讀者體會設計演變過程中蘊藏的大智慧。
　　本書適閤編程初學者或希望在麵嚮對象編程上有所提高的開發人員閱讀。

作者簡介

　　程傑，高級軟件工程師&高級培訓講師。從事軟件開發一綫工作近八年時間。曾在申銀萬國證券公司、上海楊浦區政府、朝華集團下屬網遊公司、香港晨興集團等多行業項目開發中擔任主程及項目負責人，有豐富的大中型軟件開發經驗，以及多年的軟件設計與項目管理經驗。曾任加拿大慧橋培訓中心講師，主持.NET高級軟件工程師的培訓工作；早年從事高中數學教學工作，曾在江蘇常州重點高中任教時獲得過市教學一等奬，這些教學和培訓經曆讓作者對如何以易懂的語言講解艱深的技術知識有瞭深刻的理解。他也是“博客園”網站的博客http：//cj723.cnblogs.com/的連載文章《小菜編程成長記》的作者。
　　本書作者集多年實際項目開發經驗和豐富教學培訓經驗於一身，準確把握住編程初學者的視角，以淺顯幽默的語言嚮讀者詮釋瞭麵嚮對象設計模式的精髓。

目錄

第1章 代碼無錯就是優？--簡單工廠模式
1.1 麵試受挫
1.2 初學者代碼毛病
1.3 代碼規範
1.4 麵嚮對象編程
1.5 活字印刷，麵嚮對象
1.6 麵嚮對象的好處
1.7 復製vs.復用
1.8 業務的封裝
1.9 緊耦閤vs.鬆耦閤
1.10 簡單工廠模式
1.11 UML類圖
第2章 商場促銷--策略模式
2.1 商場收銀軟件
2.2 增加打摺
2.3 簡單工廠實現
2.4 策略模式
2.5 策略模式實現
2.6 策略與簡單工廠結閤
2.7 策略模式解析
第3章 拍攝UFO--單一職責原則
3.1 新手機
3.2 拍攝
3.3 沒用的東西
3.4 單一職責原則
3.5 方塊遊戲的設計
3.6 手機職責過多嗎？
第4章 考研求職兩不誤--開放-封閉原則
4.1 考研失敗
4.2 開放-封閉原則
4.3 何時應對變化
4.4 兩手準備，並全力以赴
第5章 會修電腦不會修收音機？--依賴倒轉原則
5.1 MM請求修電腦
5.2 電話遙控修電腦
5.3 依賴倒轉原則
5.4 裏氏代換原則
5.5 修收音機
第6章 穿什麼有這麼重要？--裝飾模式
6.1 穿什麼有這麼重要？
6.2 小菜扮靚第一版
6.3 小菜扮靚第二版
6.4 裝飾模式
6.5 小菜扮靚第三版
6.6 裝飾模式總結
第7章 為彆人做嫁衣--代理模式
7.1 為彆人做嫁衣！
7.2 沒有代理的代碼
7.3 隻有代理的代碼
7.4 符閤實際的代碼
7.5 代理模式
7.6 代理模式應用
7.7 秀纔讓小六代其求婚
第8章 雷鋒依然在人間--工廠方法模式
8.1 再現活雷鋒
8.2 簡單工廠模式實現
8.3 工廠方法模式實現
8.4 簡單工廠vs.工廠方法
8.5 雷鋒工廠
第9章 簡曆復印--原型模式
9.1 誇張的簡曆
9.2 簡曆代碼初步實現
9.3 原型模式
9.4 簡曆的原型實現
9.5 淺復製與深復製
9.6 簡曆的深復製實現
9.7 復製簡曆vs.手寫求職信
第10章 考題抄錯會做也白搭--模闆方法模式
10.1 選擇題不會做，濛唄！
10.2 重復=易錯+難改
10.3 提煉代碼
10.4 模闆方法模式
10.5 模闆方法模式特點
10.6 主觀題，看你怎麼濛
第11章 無熟人難辦事？--迪米特法則
11.1 第一天上班
11.2 無熟人難辦事
11.3 迪米特法則
第12章 牛市股票還會虧錢？--外觀模式
12.1 牛市股票還會虧錢？
12.2 股民炒股代碼
12.3 投資基金代碼
12.4 外觀模式
12.5 何時使用外觀模式
第13章 好菜每迴味不同--建造者模式
13.1 炒麵沒放鹽
13.2 建造小人一
13.3 建造小人二
13.4 建造者模式
13.5 建造者模式解析
13.6 建造者模式基本代碼
第14章 老闆迴來，我不知道--觀察者模式
14.1 老闆迴來？我不知道！
14.2 雙嚮耦閤的代碼
14.3 解耦實踐一
14.4 解耦實踐二
14.5 觀察者模式
14.6 觀察者模式特點
14.7 觀察者模式的不足
14.8 事件委托實現
14.9 事件委托說明
14.10 石守吉失手機後的委托
第15章 就不能不換DB嗎？--抽象工廠模式
15.1 就不能不換DB嗎？
15.2 最基本的數據訪問程序
15.3 用瞭工廠方法模式的數據訪問程序
15.4 用瞭抽象工廠模式的數據訪問程序
15.5 抽象工廠模式
15.6 抽象工廠模式的優點與缺點
15.7 用簡單工廠來改進抽象工廠
15.8 用反射+抽象工廠的數據訪問程序
15.9 用反射+配置文件實現數據訪問程序
15.10 無癡迷，不成功
第16章 無盡加班何時休--狀態模式
16.1 加班，又是加班！
16.2 工作狀態-函數版
16.3 工作狀態-分類版
16.4 方法過長是壞味道
16.5 狀態模式
16.6 狀態模式好處與用處
16.7 工作狀態-狀態模式版
第17章 在NBA我需要翻譯--適配器模式
17.1 在NBA我需要翻譯！
17.2 適配器模式
17.3 何時使用適配器模式
17.4 籃球翻譯適配器
17.5 適配器模式的.NET應用
17.6 扁鵲的醫術
第18章 如果再迴到從前--備忘錄模式
18.1 如果再給我一次機會……
18.2 遊戲存進度
18.3 備忘錄模式
18.4 備忘錄模式基本代碼
18.5 遊戲進度備忘
第19章 分公司=一部門--組閤模式
19.1 分公司不就是一部門嗎？
19.2 組閤模式
19.3 透明方式與安全方式
19.4 何時使用組閤模式
19.5 公司管理係統
19.6 組閤模式好處
第20章 想走？可以！先買票--迭代器模式
20.1 乘車買票，不管你是誰！
20.2 迭代器模式
20.3 迭代器實現
20.4 .NET的迭代器實現
20.5 迭代高手
第21章 有些類也需計劃生育--單例模式
21.1 類也需要計劃生育
21.2 判斷對象是否是null
21.3 生還是不生是自己的責任
21.4 單例模式
21.5 多綫程時的單例
21.6 雙重鎖定
21.7 靜態初始化
第22章 手機軟件何時統一--橋接模式
22.1 憑什麼你的遊戲我不能玩
22.2 緊耦閤的程序演化
22.3 閤成/聚閤復用原則
22.4 鬆耦閤的程序
22.5 橋接模式
22.6 橋接模式基本代碼
22.7 我要開發"好"遊戲
第23章 烤羊肉串引來的思考--命令模式
23.1 吃烤羊肉串！
23.2 燒烤攤vs.燒烤店
23.3 緊耦閤設計
23.4 鬆耦閤設計
23.5 鬆耦閤後
23.6 命令模式
23.7 命令模式作用
第24章 加薪非要老總批？--職責鏈模式
24.1 老闆，我要加薪！
24.2 加薪代碼初步
24.3 職責鏈模式
24.4 職責鏈的好處
24.5 加薪代碼重構
24.6 加薪成功
第25章 世界需要和平--中介者模式
25.1 世界需要和平！
25.2 中介者模式
25.3 安理會做中介
25.4 中介者模式優缺點
第26章 項目多也彆傻做--享元模式
26.1 項目多也彆傻做！
26.2 享元模式
26.3 網站共享代碼
26.4 內部狀態與外部狀態
26.5 享元模式應用
第27章 其實你不懂老闆的心--解釋器模式
27.1 其實你不懂老闆的心
27.2 解釋器模式
27.3 解釋器模式好處
27.4 音樂解釋器
27.5 音樂解釋器實現
27.6 料事如神
第28章 男人和女人--訪問者模式
28.1 男人和女人！
28.2 最簡單的編程實現
28.3 簡單的麵嚮對象實現
28.4 用瞭模式的實現
28.5 訪問者模式
28.6 訪問者模式基本代碼
28.7 比上不足，比下有餘
第29章 OOTV杯超級模式大賽--模式總結
29.1 演講任務
29.2 報名參賽
29.3 超模大賽開幕式
29.4 創建型模式比賽
29.5 結構型模式比賽
29.6 行為型模式一組比賽
29.7 行為型模式二組比賽
29.8 決賽
29.9 夢醒時分
29.10 沒有結束的結尾
附 錄 A 培訓實習生--麵嚮對象基礎
A.1 培訓實習生
A.2 類與實例
A.3 構造方法
A.4 方法重載
A.5 屬性與修飾符
A.6 封裝
A.7 繼承
A.8 多態
A.9 重構
A.10 抽象類
A.11 接口
A.12 集閤
A.13 泛型
A.14 委托與事件
A.15 客套
附 錄 B 參考文獻

前言/序言

　　本書是一本程序集？NO。
　　本書是一本故事集？NO。
　　本書是一本通過故事講述程序如何設計的方法集。
　　本書是給連Hello World都沒寫過的非程序員看的書嗎？NO。
　　本書是給玩過穿孔紙帶（0/1）、寫過匯編、BASIC、C、C++、Delphi、Java、C#等語言，開發過覆蓋全球、使用人數過億、數百萬行代碼等大型係統的骨灰級程序員看的書嗎？NO。
　　本書希望能給渴望瞭解OO世界的初學者、睏惑於僵硬、脆弱、無法復用的代碼編程體驗者、一直打著OO編程的旗號，做著過程式開發的基於對象的編程實踐者一些好的建議和提示。
　　本書起因
　　寫本書源於我一次做培訓的經曆，學生大多是計算機專業的學生或有過一定經驗的在職開發者。他們都知道類、方法、構造方法、甚至抽象類、接口等概念，並用 Visual Studio寫過不少的Windows或Web程序，可是當我提問為什麼要用麵嚮對象，它的好處在哪裏時，卻沒有人能完整地講得齣來，多數人的反應是，概念知道的，就是錶達不清楚。
　　針對於此，我就舉瞭中國古代的四大發明中活字印刷的例子（見第1章），通過一個虛構的三國曹操做詩的情景，把麵嚮對象的幾大好處講解瞭一下，學生普遍都感覺通俗易懂，覺得這樣的教學比直接告訴麵嚮對象有什麼好處要更加容易理解和記憶。
　　這就使得我不斷地思考這樣一個問題，學一門技術是否需要趣味性、通俗性的引導。
　　我在思考中發現，看小說時，一般情況下我都可以完整地讀完它，而閱讀技術方麵的圖書，卻很少有真正的每章每頁的仔細閱讀。盡管這兩者是有很大區彆，技術書中可能有不少知識是已經學會或暫時用不上的內容，但也不得不承認，小說之所以可以堅持讀完是因為對它感興趣，作者的文字吸引你。而有些技術書的枯燥乏味使得閱讀産生瞭睏難，通常讀個前幾章就留待以後再說瞭。
　　技術課的教學同樣如此，除非學生是抱著極大的學習動機來參與其中，否則照本宣科的教學、枯燥乏味的講解，學生一定會被龐雜的概念和復雜的邏輯攪暈瞭頭腦，緻使效果大打摺扣。也正因為此，往往造成部分學生，學瞭四年的計算機編程，卻可能連麵嚮對象有什麼好處都還說不清。
　　為什麼不可以讓技術書帶點趣味性呢，哪怕這些趣味性與所講的技術並不十分貼切，隻要不是影響技術核心的本質，不産生重大的錯誤，讓讀者能輕鬆閱讀它，並且有瞭一定的瞭解和感悟，這要比一本書寫得高深無比，卻被長期束之高閣要好得多。
　　也正是這個原因，本人開始瞭關於設計模式的趣味性寫作的嘗試。
　　本書讀者
　　顯然本書不是給無任何編程經驗的人看的，對於想入這一行的朋友來說，找一門編程語言，從頭開始或許纔是正道。而本書也不太適閤有瞭多年麵嚮對象開發經驗，對常用的設計模式瞭如指掌的人看的。畢竟這裏更多的是一些基礎性的東西。
　　我時常拿程序員的成長與足球運動員的成長做對比。
　　GoF 的《設計模式》好比是世界頂級足球射門集錦，《重構》、《敏捷軟件開發》、《設計模式解析》好比是一場場最精彩的足球比賽。我為之瘋狂，為之著迷。可是我並不隻是想做一個球迷（軟件使用者），而是更希望自己能成為一個足球運動員（軟件設計編程者），能夠親自上場比賽，並且最終能成為球星（軟件架構師）。我仔細地閱讀這些被譽為經典的著作，認真地實踐其中代碼，但是我總是半途而廢、堅持不下去，我痛恨自己意誌力的薄弱、憎惡自己無端地放棄，難道我真的就是那麼的笨？
　　痛定思痛，反思悔過。我終於發現，貝利、馬拉多納不管老、胖是用來敬仰的，貝剋漢姆、羅納爾迪尼奧不管美、醜是用來欣賞的，但他們的球技……嗨，客氣地說，是不容易學會的，客觀地說，是不可能學得會的。為什麼會這樣？原來，我學習中缺瞭一個很重要的環節，我們在看到瞭精彩的球賽，欣賞球星高超球技的同時，卻忽略瞭球星的成長過程。他們盡管有一定天分，但卻也是從最底層通過努力一點一點慢慢顯露齣來的，我們需要的不僅僅是世界杯上的那定乾坤的一腳，更需要這一腳之前是如何練齣那種神奇的方法，對於程序員來講，精彩的代碼是如何想齣來的，要比看到精彩的代碼更加令人期待。
　　本書顯然不是培養足球明星（軟件架構師）的俱樂部，而是訓練足球基本功的學校，培訓的是初學足球的小球員（麵嚮對象的程序員），本書希望的是讀者閱讀後可以打好麵嚮對象的基礎，從而更加容易並深入的去理解和感受GoF的《設計模式》以及其他大師作品的魅力。
　　本書定位
　　本書是在學習眾多大師智慧結晶的圖書作品、分享瞭網上多位朋友的實踐經驗的基礎上，加之自己的編程感受寫齣來的。正如牛頓有句名言：“如果說我比彆人看得更遠些，那是因為我站在瞭巨人的肩上。”但顯然，本書並沒有創造或發現什麼模式，因此談不上站在巨人肩膀上看得更遠。所以作者更希望本書能成為一些準備攀登麵嚮對象編程高峰的朋友的登山引路人、提攜者，在您登山途中迷路時給予指引，在您峭壁攀岩摔跤時給予保護。
　　本書特色
　　本書有兩個特色，第一特色是重視過程。看瞭太多的計算機編程類的圖書，大多數書籍都是集中在講授優秀的解決方案或者一個完美的程序樣例，但對這些解決方案和程序的演變過程卻重視不夠，好書之所以好，就是因為作者可以站在學習者的角度去講解問題所在，讓學習門檻降低。《重構與模式》中有一句經典之語：“如果想成為一名更優秀的軟件設計師，瞭解優秀軟件設計的演變過程比學習優秀設計本身更有價值，因為設計的演變過程中蘊藏著大智慧。”本人就希望能通過小菜與大鳥的對話，在不斷地提問與迴答過程中，在程序的不斷重構演變中，把設計模式的學習門檻降低，讓初學者可以更加容易地理解，為什麼這樣設計纔是好，是如何想到這樣設計的。
　　本書的第二個特色就是貼近生活。盡管編程是嚴謹的，不容大話和戲說。但生活卻是多姿多彩的，而設計模式也不是完全孤立於現實世界而憑空想齣來的理論。事實上所有的模式都可以在生活中找到對應。因此，通過主人公小菜和大鳥的對話，將求職、麵試、工作、交友、投資、兼職、辦公室文化、生活百味等等非常接近程序員生活原貌的場景寫到瞭書中，用一個個小故事來引齣模式，會讓讀者相對輕鬆地進入學習設計模式的狀態。當然，此舉的最大目的還是為瞭深入淺齣，而非純粹噱頭。
　　本書內容
　　本書通篇都是以情景對話的形式，用一個又一個的小故事或編程示例來組織的。共分為四個部分。第一部分是麵嚮對象的意義和好處以及幾個重要的設計原則，通過小菜麵試的失敗引齣；第二部分是詳細講解23個設計模式；第三部分是對設計模式的總結，利用小菜夢到的超級模式大賽的場景，把所有的麵嚮對象和模式概念都擬人化來趣味性的總結設計模式之間的異同和關鍵點。第四部分是附錄，主要是針對對麵嚮對象不熟悉讀者的一個補充，通過一個例子的演變介紹瞭類、封裝、繼承、多態、接口、事件等概念。
　　本書人物及背景
　　小菜：原名蔡遙，22歲，上海人，上海某大學計算機專業大學四年級學生，成績一般，考研剛結束，即將畢業，正求職找工作。
　　大鳥：原名李大遼，29歲，小菜的錶哥，雲南昆明人，畢業後長期從事軟件開發和管理工作，近期到上海發展，藉住小菜傢在寶山的空套房內。小菜以嚮大鳥學習為由，也從市區父母傢搬到寶山與大鳥同住。
　　本書研讀方法
　　本書建議按順序閱讀，如果您感覺由於麵嚮對象知識的匱乏，例如對繼承、多態、接口、抽象類的理解不足，造成閱讀上的睏難，不妨先閱讀附錄一的“培訓實習生——麵嚮對象基礎”部分，然後再從第1章開始閱讀。如果您已經對不少設計模式熟悉，也不妨挑選不熟悉的模式章節閱讀。
　　盡管本書中的代碼都提供下載，但不經過讀者的自己手動輸入過程，其實閱讀的效果是大打摺扣的。強烈建議讀者根據樣例自己寫程序，隻有在運行齣錯，達不到預期效果時再查看本書提供的源程序，這樣或許纔是最好的學習方法。有問題可及時與我聯係。我的電子郵箱是chengjielong@163.com，博客是 http：//cj723.cnblogs.com/。
　　本書中的很多精華都來自許多大師作品，建議讀者通過筆記形式記錄，這將有助於您的記憶和理解設計模式，增強最終的讀書效果。
　　本書中齣現的“[ ]”是錶示句子摘自某書。例如，“策略模式（Strategy）：它定義瞭算法傢族，分彆封裝起來，讓它們之間可以互相替換，此模式讓算法的變化不會影響到使用算法的客戶[DP]。”其中“[DP]”錶示此名摘自《設計模式：可復用麵嚮對象軟件的基礎》，詳細摘要說明請參看附錄二。
　　本書中29章中的虛擬人物姓名都是軟件編程中的專業術語，因此凡是專業術語被指嚮人物姓名的都用斜體字錶示，以和實際術語區分。例如，“第一位是我們OOTV創始人，麵嚮對象先生”，這裏的斜體字麵嚮對象指人名。
　　關於本書學習的疑問解答
　　看本書需要什麼基礎？
　　主要是C#或其他編程語言的基礎知識，如變量、分支判斷、循環、函數等編程基礎，關於麵嚮對象基礎可參看本書的附錄一。
　　設計模式是否有必要全部學一遍？
　　答案是，Yes！彆被那些說什麼設計模式大多用不上，根本不用全學的輿論所左右。盡管現在設計模式遠遠不止23種，對所有都有研究是不太容易的，但就像作者本人一樣，在學習GoF總結的23個設計模式過程中，你會被那些編程大師們進行偉大的技術思想洗禮，不斷增加自己對麵嚮對象的深入理解，從而更好的把這種思想發揚光大。這就如同高中時學立體幾何感覺沒用，但當你裝修好房子購買傢俱時纔知道，有空間感，懂得空間計算是如何的重要，你完全可能遇到買瞭一個大號的冰箱卻放不進廚房，或買瞭開關門的衣櫥（移門不占空間）卻因床在旁邊堵住瞭門而打不開的尷尬。
　　重要的不是你將來會不會用到這些模式，而是通過這些模式讓你找到“封裝變化”、“對象間鬆散耦閤”、“針對接口編程”的感覺，從而設計齣易維護、易擴展、易復用、靈活性好的程序。成為詩人後可能不需要刻意地按照某種模式去創作，但成為詩人前他們一定是認真地研究過成百上韆的唐詩宋詞、古今名句。
　　如果說，數學是思維的體操，那設計模式，就是麵嚮對象編程思維的體操。
　　我學瞭設計模式後時常會過度設計，如何辦？
　　作者建議，暫時現象，繼續努力。
　　設計模式有四境界：
　　1．沒學前是一點不懂，根本想不到用設計模式，設計的代碼很糟糕；
　　2．學瞭幾個模式後，很開心，於是到處想著要用自己學過的模式，於是時常造成誤用模式而不 自知；
　　3．學完全部模式時，感覺諸多模式極其相似，無法分清模式之間的差異，有睏惑，但深知誤用之害，應用之時有所猶豫；
　　4．靈活應用模式，甚至不應用具體的某種模式也能設計齣非常優秀的代碼，以達到無劍勝有劍的境界。
　　從作者本人的觀點來說，不會用設計模式的人要遠遠超過過度使用設計模式的人，從這個角度講，因為怕過度設計而不用設計模式顯然是因噎廢食。當你認識到自己有過度使用模式的時候，那就證明你已意識到問題的存在，隻有通過不斷的鑽研和努力，你纔能突破“不識廬山真麵目，隻緣身在此山中”的瓶頸，達到“會當淩絕頂，一覽眾山小”的境界。
　　編程語言的差異
　　本書講的是麵嚮對象設計模式，是用.NET中的C#語言編寫，但本書並不是主要講解C#語言或.NET框架的圖書，因此本書同樣適閤Java、VB.NET、C++等其他一些麵嚮對象語言的讀者閱讀來學習設計模式。
　　就Java而言，主要差異來自C#對於子類繼承父類或實現接口用的都是“：”，而Java中兩者是有區彆的。
　　當Cat繼承抽象類Animal時，Java
　　語法是public class Cat extends Animal
　　當Superman實現接口IFly時，Java語法是
　　public class Superman implements IFly
　　然後Java中所有的方法都是虛擬的，因此不用指定new或是override修飾符。還有一些其他差異，但基本都不影響本書的閱讀。
　　對於VB.NET的程序員，如果閱讀睏難，不妨去網上查找關於轉換C#與VB.Net語言的工具，比如http：//www.kamalpatel.net/ConvertCSharp2VB.aspx，將下載本書的源代碼轉換後再進行閱讀。
　　C++的程序員，可能在語言上會有些差異，不過本書應該不會因為語言造成對麵嚮對象思想的誤讀。
　　不是一個人在戰鬥
　　首先要感謝我的妻子李秀芳對我寫作本書期間的全力支持，沒有她的理解和鼓勵，就不可能有本書的齣版。而我們的寶寶也將在2008年初齣生，希望等寶寶懂事後能知道，在寶寶的母親懷胎過程中，寶寶的父親也在為書的誕生而努力。也希望本書成為贈送給他或者她的最好的禮物。
　　父母的養育纔有作者本人的今天，本書的齣版，尋根溯源，也是父母用心教育的結果。養育之恩，沒齒難忘。
　　本書起源於本人在“博客園”網站的博客http：//cj723.cnblogs.com/中的一個連載文章《小菜編程成長記》。沒想到連載引起瞭不小的反應，網友們普遍認為本人的這種技術寫作方式新穎、有趣、喜歡看。正是因為眾多網友的支持，本人有瞭要把GoF的23種設計模式全部成文的衝動。非常感謝這些在博客迴復中鼓勵我的朋友。
　　這裏需要特彆提及洪立人先生，他是本人在寫書期間共同為理想奮鬥的戰友，寫作也得到瞭他的大力支持和幫助，我寫作的不少妙句也來自我們倆共同閤作的網站http：//www.miaoju.net。在此對兩位錶示衷心的感謝。
　　寫作過程中，本人參考瞭許多國內外大師的設計模式的著作。尤其是《設計模式》（作者：簡稱GoF的Erich Gamm，Richard Helm，Ralph Johnson，John Vlissides）、《設計模式解析》（作者：Alan Shalloway，James R. Trott）、《敏捷軟件開發：原則、模式與實踐》（作者：Robert C.Martin）、《重構——改善既有代碼的設計》（作者：Martin Fowler）、《重構與模式》（作者：Joshua Kerievsky）、《Java與模式》（作者：閻宏等等，沒有他們的貢獻，就沒有本書的齣版。也希望本書能成為更好閱讀他們這些大師作品的前期讀物。
　　寫作過程中，本人還參考瞭http：//www.dofactory.com/ 關於23個設計模式的講解，並引用瞭他們的結構圖和基本代碼。在博客園中的許多朋友，比如張逸、呂震宇、李會軍、idior、Allen Lee的博文，MSDN SmartCast中李建忠的講座，CSDN博客中的大衛、ai92的博文，網站J道www.jdon.com 的版主banq的文章都給本人的寫作提供瞭非常大的指引和幫助，在此錶示感謝。另外博客園的雙魚座先生還對本人的部分代碼提齣瞭整改意見，也錶示衷心的謝意。詳細參考資料與網站鏈接，見附錄二。
　　事實上，由於本人長期有看書記讀書筆記的習慣，所以書中引用筆記的內容，也極有可能是來自某本書或者某個朋友的博客、某個網站的文章。而本人已經無法一一說齣其引用的地址，但這些作者的智慧同樣對本書的寫作帶來瞭幫助，在此隻能說聲謝謝。
　　最後，對本書的責任編輯陳冰先生及清華大學齣版社的相關工作人員，錶示由衷的感謝。本書的齣版離不開陳先生的指導和其他工作人員的辛勤工作。
　　程 傑
　　2007年7月
　　序
　　這本書最初起源於作者程傑在其博客中所寫的連載文章——《小菜編程成長記》。隨著文章的一篇篇發布，這些文章新穎的錶現形式和獨特的風格受到瞭眾多讀者的關注和喜愛，很多人在博客中留下瞭評語。有些雖然隻有短短的一句話，但也可以看齣是對作者由衷的感謝。作為本書的策劃編輯，最初我也是在博客園中瀏覽博文時閱讀到這些文章的，我的直覺和網友們熱情洋溢的評語告訴我，這些文章有作為一部書齣版的價值，於是我就聯係瞭程傑。幾個月後，我拿到瞭這部書的初稿。
　　初審後，我發現書稿中存在一些問題。比如，當時書稿中還沒有對UML類圖進行講解的內容，這會導緻初學者學習後麵的內容時感到理解睏難，於是我請作者在第1 章中增加瞭UML類圖這一節，這是簡潔卻精彩的一節；另外，當時作者為瞭便於錶達某些舉例的含義，有相當數量的代碼都是用中文編寫的，雖然中文代碼看似易懂，但卻會令絕大多數早已熟悉瞭英文代碼的程序員們感到睏惑和難以閱讀，所以我請作者把代碼改迴為程序員們所熟悉的英文代碼，並同時添加瞭更詳細的中文注釋。經過幾番認真和辛苦的修改與調整，現在，這本書在你的手中瞭。
　　對於這本書，我想說的是，其中的很多篇章非常的精彩，會令你禁不住叫好，但也有一些篇章會顯得有些拖遝，或者是有些牽強，然而，隨著你讀過那些精彩的段落，讀過那些不那麼精彩的段落，最終，你會讀到書的最後一頁（很多書不能使你做到這一點），當你讀完全書時，你會發現，你的心情很愉快，很平靜，即使是那些當時看起來不那麼精彩的段落，現在也都成為瞭這溫馨故事的一部分。你會記得書中那個好學、天真、而又執著的小菜，也會記得那個善於啓發，經驗老道的大鳥。
　　下麵這些是來自作者博客的網友評論，看完這些熱情洋溢的評論，就和作者一起，進入設計模式的大話境界吧。
　　本書策劃編輯 陳冰
　　2007年10月18日
　　網友評論
　　daigua：看到這篇精彩的成長記，我連飯都不想吃瞭，什麼事都不想做，就想把它看完。寫得太好瞭！是啊，現在很多教材都太枯燥瞭，不好理解。其實書的意義就在於讓人學到知識，而不在於用什麼方式，為什麼一定要那麼教條呢，隻要能讓人比較容易地學到書裏的知識就是一本好書。謝謝你啊，給瞭我很大的信心。我現在很有信心把編程進行到底，哈哈。
　　光頭小鬆鼠：絕對經典！一篇小故事，把程序的靈活性、可擴展性、可維護、可復用等說得怎一個妙字瞭得！
　　沉默天蠍：感激，讓我這個菜鳥頓悟。這樣的寫法太好瞭，如果老大你齣書，我肯定購買！
　　碳碳：這種學習的方式真的很神奇，盡管每個人都能想到，但不是每個人都能做到。或許可以把係列文章歸檔齣書，說不定會收到追捧，嗬嗬。
　　Bryant：真的是太棒瞭！我原來看過一些有關設計模式的書，都覺得太抽象，根本就不能理解，也不知道啥時候能用上。看過你寫的這些文章，纔知道瞭應該怎樣在實際中運用這些模式，而且文筆非常的幽默，享受！Thx ^_^ 支持！有個建議，最好慢慢地把所有的設計模式都聊聊！
　　Bryant：不錯，樓主說的非常幽默，通俗，把我們一步一步帶入麵嚮對象的世界 thx ^_^
　　Bryant：太棒瞭，我正是這樣初學設計模式的小菜，需要這樣的文章，謝謝樓主！
　　菜鳥飛：樓主，加油，支持你。在這裏獻上崇高的敬意，不管你有沒有感受到我摯熱的目光。請你相信，有這樣一些人一直在默默地關注著你，期待著你。
　　wdx2008：非常好！！！幽默，搞笑，易懂，真神人也，鬼神不可測！支持樓主！！
　　空明流轉：嗬嗬，樓主說得蠻好。國外的文章好就好在有例子，“廢話”多，所以比較好理解。至於行文風格嘛，這個倒是因人而異的。我個人就偏嚮於論文式的行文風格，邏輯嚴密，層層遞進，闡述也很清晰。就有點像有序數組，二分法就能輕鬆查找到自己想要的東西，但國內的那種論文式的文章，嗬嗬，我看是賣弄的成分居多，實作的成分偏少，所以纔那麼難讀的吧。
　　Char：現在的大學就缺少這種既通俗易懂，又有內容的東西。
　　Apple：不錯，學習瞭。希望博主能再接再厲多寫點，看瞭很多書都沒有看你的文章明白得快。
　　SnowDoggie：嗬嗬，挺好的。其實要想找個絕對沒有漏洞的例子是很辛苦的，關鍵在於文章本身能說明問題，能體現作者的意圖就足夠瞭。昨天和朋友一起爬山的時候還討論瞭你的文章風格，其實最有用的還是你這種寓教於樂，步步深入的風格，陽春白雪的經典雖然是經典，大眾卻不見得喜歡。
　　Jerry：不錯的文章，簡單明瞭，又不乏趣味，好的文章就得頂下。
　　izhizhe2000：很好，整個係列寫完之後可以齣書瞭，保證受大學生的廣泛歡迎！
　　mekong：很是欣賞這樣幽默風趣又不失睿智深刻的文字。
　　Wuyisky：嗬嗬，樓主不僅程序寫得好，而且還有文學天賦。佩服！
　　Jack：真正的高手是用最生動的語言，最簡單的例子，這纔是真正的“深入淺齣”。贊！！！老兄，加油，繼續喲。
　　BoyLee：人纔，愛死你瞭。做瞭一年外包，沒技術含量。正打算從頭學習這些東西，這樣的方式我最喜歡瞭。
　　Leoxu：很不錯，對正在找工作的我有很大的幫助。以後會多來光顧。
　　Ame：寫得承上啓下，始終有一主乾綫貫穿，作者的文字功底很強啊！
　　Artech：我很喜歡你的寫作風格！以一種調侃的方式講明一個深奧的問題。我一直在嘗試如何以一種讓每個人都懂得的語言來嚮大傢分享我所理解的.NET。你給瞭我一個啓發。
　　8：醍醐灌頂！感謝，領悟瞭不少東西！！！
　　Yufengly：真是太容易理解瞭，而且看後印象深刻，繼續努力！期待下文……支持作者！
　　Sopper：支持，例子舉得很形象，寫得很棒，以後會常來關注。
　　d：會技術的高人有很多，但能把技術講得如此通俗易懂的高人並不多，你是一個，謝謝～～～
　　white.wu：非常喜歡您這種授人以“漁”的文章。
　　Answer：強啊，本菜鳥受益很大，謝謝。
　　Hanlei：強，很受益啊，感謝樓主，寫齣這麼好的文章來。
　　金色海洋（jyk）：繼續呀，我們期待中……，寫得很好，一看就懂。
　　DSharp：看博客園這麼久瞭，終於看到一篇有中國特色的好文。

评分☆☆☆☆☆

还没看，但是看了很多评价，希望自己能静下心，好好学习进步，加油！

评分☆☆☆☆☆

刚好京东图书搞活动，一下子买了好多的技术书籍，希望今年的自己的技术能够有大的提升，非常满意，书都非常好

评分☆☆☆☆☆

书还可以，活动挺划算

评分☆☆☆☆☆

不错，正是我需要的，还干上了活动，不错

评分☆☆☆☆☆

方便快捷，书本很好，无污渍破损，看看轻松点的讲法

评分☆☆☆☆☆

可以。。。。。。。。。。。。。。。。。。。

评分☆☆☆☆☆

性价比超高，发货速度，一直信赖京东，无论是商品，发货速度。还是配送，都非常棒

评分☆☆☆☆☆

大佬推荐的书，值得学习借鉴

评分☆☆☆☆☆

搞活动买的，价格合适，优惠多多！！！！