　　《大話設計模式》是準備攀登麵嚮對象編程高峰朋友們的引路人和提攜者；《大話設計模式》是學習、體會和領悟瞭眾多大師智慧結晶後的圖書作品；《大話設計模式》是你深入理解和感受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/。
　　本書中的很多精華都來自許多大師作品，建議讀者通過筆記形式記錄，這將有助於您大話設計模式下載 mobi epub pdf txt 電子書格式