敏捷軟件開發(fā)

內容概要

　　享譽全球的面向對象技術大師Robert C. Martin在《敏捷軟件開發(fā)：原則、模式與實踐(C#版·修訂版)》中深入而生動地使用真實案例講解了面向對象設計的基本原則、重要的設計模式、UML和敏捷方法。
　　《敏捷軟件開發(fā)：原則、模式與實踐(C#版·修訂版)》Java版曾榮獲2003年第13屆Jolt大獎，是公認的典著作?！睹艚蒈浖_發(fā)：原則、模式與實踐(C#版·修訂版)》是C#程序員提升功力的絕佳教程，也可用作高校計算機、軟件工程專業(yè)本科生、研究生的教材或參考書。

作者簡介

Robert C. Martin（Bob大叔）世界級軟件開發(fā)大師，著名軟件咨詢公司Object Mentor公司的創(chuàng)始人和總裁。曾擔任C++ Report雜志主編多年，也是設計模式和敏捷開發(fā)運動的主要倡導者之一。
Micah Martin  Robert C. Martin之子，也是經驗豐富的軟件工程師，曾任Object Mentor公司的咨詢師，現任8th Light公司總裁。擅長.NET、面向對象技術、模式和敏捷開發(fā)。他是開源測試工具FitNesse的主要開發(fā)者。

書籍目錄

目　錄
 
第一部分　敏捷開發(fā)
第1章　敏捷實踐　3
1.1　敏捷聯盟　4
1.1.1　人和交互重于過程和工具　4
1.1.2　可以工作的軟件重于面面俱到的文檔　5
1.1.3　客戶合作重于合同談判　5
1.1.4　隨時應對變化重于遵循計劃　6
1.2　原則　6
1.3　結論　8
1.4　參考文獻　8
第2章　極限編程概述　9
2.1　極限編程實踐　9
2.1.1　完整團隊　9
2.1.2　用戶故事　10
2.1.3　短交付周期　10
2.1.4　驗收測試　10
2.1.5　結對編程　11
2.1.6　測試驅動開發(fā)　11
2.1.7　集體所有　12
2.1.8　持續(xù)集成　12
2.1.9　可持續(xù)的開發(fā)速度　12
2.1.10　開放的工作空間　13
2.1.11　計劃游戲　13
2.1.12　簡單設計　13
2.1.13　重構　14
2.1.14　隱喻　14
2.2　結論　15
2.3　參考文獻　15
第3章　計劃　16
3.1　初始探索　17
3.2　發(fā)布計劃　17
3.3　迭代計劃　18
3.4　定義“完成”　18
3.5　任務計劃　18
3.6　迭代　19
3.7　跟蹤　19
3.8　結論　20
3.9　參考文獻　21
第4章　測試　22
4.1　測試驅動開發(fā)　22
4.1.1　優(yōu)先設計測試的例子　23
4.1.2　測試促使模塊之間隔離　24
4.1.3　意外獲得的解耦合　25
4.2　驗收測試　26
4.3　意外獲得的構架　27
4.4　結論　27
4.5　參考文獻　28
第5章　重構　29
5.1　素數產生程序：一個簡單的重構示例　30
5.1.1　單元測試　31
5.1.2　重構　32
5.1.3　最后審視　35
5.2　結論　38
5.3　參考文獻　39
第6章　一次編程實踐　40
6.1　保齡球比賽　40
6.2　結論　75
第二部分　敏捷設計
第7章　什么是敏捷設計　81
7.1　設計臭味　81
7.1.1　設計臭味——腐化軟件的氣味　82
7.1.2　僵化性　82
7.1.3　脆弱性　82
7.1.4　頑固性　82
7.1.5　粘滯性　82
7.1.6　不必要的復雜性　83
7.1.7　不必要的重復　83
7.1.8　晦澀性　83
7.2　軟件為何會腐化　84
7.3　Copy程序　84
7.3.1　熟悉的場景　84
7.3.2　Copy程序的敏捷設計　87
7.4　結論　88
7.5　參考文獻　88
第8章　SRP：單一職責原則　89
8.1　定義職責　90
8.2　分離耦合的職責　91
8.3　持久化　92
8.4　結論　92
8.5　參考文獻　92
第9章　OCP：開放-封閉原則　93
9.1　OCP概述　94
9.2　Shape應用程序　95
9.2.1　違反OCP　95
9.2.2　遵循OCP　97
9.2.3　預測變化和“貼切的”結構　98
9.2.4　放置吊鉤　99
9.2.5　使用抽象獲得顯式封閉　99
9.2.6　使用“數據驅動”的方法獲取封閉性　100
9.3　結論　101
9.4　參考文獻　101
第10章　LSP：Liskov替換原則　102
10.1　違反LSP的情形　103
10.1.1　簡單例子　103
10.1.2　更微妙的違反情形　104
10.1.3　實際的例子　108
10.2　用提取公共部分的方法代替繼承　111
10.3　啟發(fā)式規(guī)則和習慣用法　113
10.4　結論　114
10.5　參考文獻　114
第11章　DIP：依賴倒置原則　115
11.1　層次化　116
11.1.1　倒置的接口所有權　117
11.1.2　依賴于抽象　117
11.2　簡單的DIP示例　117
11.3　熔爐示例　119
11.4　結論　121
11.5　參考文獻　121
第12章　ISP：接口隔離原則　122
12.1　接口污染　122
12.2　分離客戶就是分離接口　123
12.3　類接口與對象接口　124
12.3.1　使用委托分離接口　124
12.3.2　使用多重繼承分離接口　125
12.4　ATM用戶界面的例子　126
12.5　結論　131
12.6　參考文獻　131
第13章　寫給C#程序員的UML概述　132
13.1　類圖　134
13.2　對象圖　135
13.3　順序圖　136
13.4　協(xié)作圖　136
13.5　狀態(tài)圖　137
13.6　結論　137
13.7　參考文獻　137
第14章　使用UML　138
14.1　為什么建?！?38
14.1.1　為什么構建軟件模型　139
14.1.2　編碼前應該構建面面俱到的設計嗎　139
14.2　有效使用UML　139
14.2.1　與他人交流　139
14.2.2　脈絡圖　141
14.2.3　項目結束文檔　142
14.2.4　要保留的和要丟棄的　142
14.3　迭代式改進　143
14.3.1　行為優(yōu)先　143
14.3.2　檢查結構　144
14.3.3　想象代碼　146
14.3.4　圖的演化　147
14.4　何時以及如何繪制圖示　147
14.4.1　何時要畫圖，何時不要畫圖　147
14.4.2　CASE 工具　148
14.4.3　那么，文檔呢　149
14.5　結論　149
第15章　狀態(tài)圖　150
15.1　基礎知識　150
15.1.1　特定事件　151
15.1.2　超狀態(tài)　152
15.1.3　初始偽狀態(tài)和結束偽狀態(tài)　153
15.2　使用FSM圖示　153
15.3　結論　154
第16章　對象圖　155
16.1　即時快照　155
16.2　主動對象　156
16.3　結論　159
第17章　用例　160
17.1　編寫用例　160
17.1.1　備選流程　161
17.1.2　其他東西呢　161
17.2　用例圖　162
17.3　結論　162
17.4　參考文獻　162
第18章　順序圖　163
18.1　基礎知識　163
18.1.1　對象、生命線、消息及其他　164
18.1.2　創(chuàng)建和析構　164
18.1.3　簡單循環(huán)　165
18.1.4　時機和場合　166
18.2　高級概念　168
18.2.1　循環(huán)和條件　168
18.2.2　耗費時間的消息　169
18.2.3　異步消息　171
18.2.4　多線程　174
18.2.5　主動對象　175
18.2.6　向接口發(fā)送消息　175
18.3　結論　175
第19章　類圖　177
19.1　基礎知識　177
19.1.1　類　177
19.1.2　關聯　178
19.1.3　繼承　179
19.2　類圖示例　180
19.3　細節(jié)　181
19.3.1　類衍型　181
19.3.2　抽象類　182
19.3.3　屬性　183
19.3.4　聚集　183
19.3.5　組合　184
19.3.6　多重性　185
19.3.7　關聯衍型　186
19.3.8　內嵌類　187
19.3.9　關聯類　187
19.3.10　關聯修飾符　187
19.4　結論　188
19.5　參考文獻　188
第20章　咖啡的啟示　189
20.1　Mark IV型專用咖啡機　189
20.1.1　規(guī)格說明書　190
20.1.2　常見的丑陋方案　192
20.1.3　虛構的抽象　193
20.1.4　改進方案　194
20.1.5　實現抽象模型　198
20.1.6　這個設計的好處　209
20.2　面向對象過度設計　214
20.3　參考文獻　214
第三部分　薪水支付案例研究
第21章　COMMAND模式和ACTIVE OBJECT模式：多功能與多任務　219
21.1　簡單的Command　220
21.2　事務　221
21.2.1　實體上解耦和時間上解耦　222
21.2.2　時間上解耦　223
21.3　Undo()方法　223
21.4　ACTIVE OBJECT模式　224
21.5　結論　227
21.6　參考文獻　228
第22章　TEMPLATE METHOD模式和STRATEGY模式：繼承和委托　229
22.1　TEMPLATE METHOD模式　230
22.1.1　濫用模式　232
22.1.2　冒泡排序　232
22.2　STRATEGY模式　235
22.3　結論　239
22.4　參考文獻　239
第23章　FACADE模式和MEDIATOR模式　240
23.1　FACADE模式　240
23.2　MEDIATOR模式　241
23.3　結論　243
23.4　參考文獻　243
第24章　SINGLETON模式和MONOSTATE模式　244
24.1　SINGLETON模式　245
24.1.1　SINGLETON模式的好處　246
24.1.2　SINGLETON模式的代價　246
24.1.3　運用SINGLETON模式　246
24.2　MONOSTATE模式　247
24.2.1　MONOSTATE模式的好處　249
24.2.2　MONOSTATE模式的代價　249
24.2.3　運用MONOSTATE模式　249
24.3　結論　253
24.4　參考文獻　253
第25章　NULL OBJECT模式　254
25.1　描述　254
25.2　結論　256
25.3　參考文獻　256
第26章　薪水支付案例研究：第一次迭代開始　257
26.1　初步的規(guī)格說明　257
26.2　基于用例分析　258
26.2.1　增加新雇員　259
26.2.2　刪除雇員　260
26.2.3　登記考勤卡　260
26.2.4　登記銷售憑條　260
26.2.5　登記工會服務費　261
26.2.6　更改雇員明細　261
26.2.7　發(fā)薪日　263
26.3　反思：找出底層的抽象　264
26.3.1　雇員支付類別抽象　264
26.3.2　支付時間表抽象　265
26.3.3　支付方式　266
26.3.4　從屬關系　266
26.4　結論　266
26.5　參考文獻　267
第27章　薪水支付案例研究：實現　268
27.1　事務　268
27.1.1　增加雇員　269
27.1.2　刪除雇員　273
27.1.3　考勤卡、銷售憑條以及服務費用　274
27.1.4　更改雇員屬性　280
27.1.5　犯了什么暈　287
27.1.6　支付雇員薪水　290
27.1.7　支付領月薪的雇員薪水　292
27.1.8　支付鐘點工薪水　294
27.2　主程序　302
27.3　數據庫　303
27.4　結論　304
27.5　關于本章　304
27.6　參考文獻　305
第四部分　打包薪水支付系統(tǒng)
第28章　包和組件的設計原則　308
28.1　包和組件　308
28.2　組件的內聚性原則：粒度　309
28.2.1　重用-發(fā)布等價原則　309
28.2.2　共同重用原則　310
28.2.3　共同封閉原則　311
28.2.4　組件內聚性總結　311
28.3　組件的耦合性原則：穩(wěn)定性　311
28.3.1　無環(huán)依賴原則　311
28.3.2　穩(wěn)定依賴原則　316
28.3.3　穩(wěn)定抽象原則　319
28.4　結論　322
第29章　FACTORY模式　323
29.1　依賴問題　325
29.2　靜態(tài)類型與動態(tài)類型　326
29.3　可替換的工廠　326
29.4　對測試支架使用對象工廠　327
29.5　工廠的重要性　328
29.6　結論　329
29.7　參考文獻　329
第30章　薪水支付案例研究：包分析　330
30.1　組件結構和符號　330
30.2　應用CCP　332
30.3　應用REP　333
30.4　耦合和封裝　335
30.5　度量　336
30.6　度量薪水支付應用程序　337
30.6.1　對象工廠　340
30.6.2　重新思考內聚的邊界　342
30.7　最終的包結構　342
30.8　結論　345
30.9　參考文獻　345
第31章　COMPOSITE模式　346
31.1　組合命令　347
31.2　多重性還是非多重性　348
31.3　結論　348
第32章　OBSERVER——演化至模式　349
32.1　數字時鐘　350
32.2　OBSERVER模式　365
32.2.1　模型　365
32.2.2　面向對象設計原則的運用　366
32.3　結論　366
32.4　參考文獻　367
第33章　ABSTRACT SERVER模式、 ADAPTER模式和BRIDGE模式　368
33.1　ABSTRACT SERVER模式　369
33.2　ADAPTER模式　370
33.2.1　類形式的ADAPTER模式　370
33.2.2　調制解調器問題、適配器以及LSP　370
33.3　BRIDGE模式　374
33.4　結論　375
33.5　參考文獻　376
第34章　PROXY模式和GATEWAY模式：管理第三方API　377
34.1　PROXY模式　377
34.1.1　實現PROXY模式　381
34.1.2　小結　391
34.2　數據庫、中間件以及其他第三方接口　392
34.3　TABLE DATA GATEWAY　394
34.3.1　測試和內存TDG　399
34.3.2　測試DbGateWay　400
34.4　可以用于數據庫的其他模式　403
34.5　結論　404
34.6　參考文獻　404
第35章　VISITOR模式　405
35.1　VISITOR模式　406
35.2　ACYCLIC VISITOR模式　409
35.3　DECORATOR模式　418
35.4　EXTENSION OBJECT模式　423
35.5　結論　432
35.6　參考文獻　432
第36章　STATE模式　433
36.1　嵌套switch/case語句　434
36.1.1　內部作用域的狀態(tài)變量　436
36.1.2　測試動作　436
36.1.3　代價和收益　436
36.2　遷移表　437
36.2.1　使用表解釋　437
36.2.2　代價和收益　438
36.3　STATE模式　439
36.3.1　STATE模式和STRATEGY模式　441
36.3.2　代價和收益　442
36.4　狀態(tài)機編譯器　442
36.4.1　SMC生成的Turnstile.cs以及其他支持文件　443
36.4.2　代價和收益　448
36.5　狀態(tài)機應用的場合　448
36.5.1　作為GUI中的高層應用策略　448
36.5.2　GUI交互控制器　450
36.5.3　分布式處理　450
36.6　結論　451
36.7　參考文獻　451
第37章　薪水支付案例研究：數據庫　452
37.1　構建數據庫　452
37.2　一個代碼設計缺陷　453
37.3　增加雇員　455
37.4　事務　464
37.5　加載Employee對象　468
37.6　還有什么工作　478
第38章　薪水支付系統(tǒng)用戶界面：Model-View-Presenter　479
38.1　界面　480
38.2　實現　481
38.3　構建窗口　489
38.4　Payroll窗口　495
38.5　真面目　504
38.6　結論　505
38.7　參考文獻　505
附錄A　雙公司記　506
Rufus公司：“日落”項目　506
Rupert工業(yè)公司：“朝陽”項目　506
附錄B　什么是軟件　516
索引　524

章節(jié)摘錄

版權頁：   插圖：   在探索UML的細節(jié)之前，我們應該先講講何時以及為何使用它。UML的誤用和濫用已經對軟件項目造成了太多的危害。 14.1為什么建模 工程師為何要構建模型？航天工程師為何要構建飛行器模型？結構工程師為何要構建橋梁模型？構建這些模型的目的是什么呢？ 這些工程師構建模型的目的是為了知道他們的設計是否可行。航天工程師構建飛行器模型并把它們放到風洞中是為了看看它們是否能夠飛行。結構工程師構建橋梁模型是為了看看它們是否能夠屹立不倒。建筑師構建建筑模型是為了看看他們的客戶是否喜歡這些建筑的樣子。構建模型就是為了弄清楚某些東西是否可行。 這意味著模型必須是可測試的。如果不能對模型應用一些可測試的標準，那么構建模型是毫無用處的。如果模型不能被評估，那么這個模型就沒有任何價值。 航天工程師為何不是直接構建一架飛機，然后就讓它試著飛行？結構工程師為何不是直接建造一座橋梁，然后看看它是否能夠屹立不倒？答案很簡單，飛機和橋 梁要比模型昂貴很多。當模型比要構建的真實實體便宜得多時，我們就會使用模型來研究設計。 14.1.1為什么構建軟件模型 UML圖是可測試的嗎？和其表示的軟件相比，它創(chuàng)建和測試起來更便宜一些嗎？針對這兩個問題，我們無法像航天工程師以及結構工程師那樣得出明顯的答案。在測試UML圖方面，沒有嚴格的標準。我們可以查看它，評估它，并應用一些原則和模式，但是評估最終仍是主觀的。繪制UML圖確實要比編寫軟件代價更小一些，但并沒有小多少。事實上，時常會出現更改源代碼比更改圖示更容易的情況。那么，在什么情況下使用UML是有意義的呢？ 如果UML沒有使用價值，那么我就不會編寫這幾章了。不過，UML確實很容易被誤用。當我們有一些確定的東西需要測試，并且使用UML要比使用代碼測試起來代價更低一些時，就使用UML。比如，我有一個關于某個設計的想法。我想知道團隊中的其他開發(fā)人員是否認為它是一個好的想法。于是，我就在白板上畫一幅UML圖，并詢問團隊成員的意見。

媒體關注與評論

本書是對敏捷編程和敏捷原則最全面和最有價值的介紹……本書絕對是所有.NET程序員必讀之作。—Jesse Liberty，微軟資深技術專家我最喜愛的技術作家Robert Martin善于通過實踐展示技術，讓讀者能夠以自己喜歡的方式逐步理解……請把Bob大叔當做你在敏捷世界里的導師?！狢hris Sells，.NET資深技術專家，微軟“軟件傳奇人物”前幾天，我找到了記有我對Bob大叔第一印象的備忘錄。上面寫著 “優(yōu)秀的對象思想”。你手中的這本書就是能讓你受益終生的“優(yōu)秀的對象思想”?！狵ent Beck，軟件開發(fā)大師，極限編程之父，設計模式先驅我期待這本書已經很久了，關于如何去掌握我們的行業(yè)技能，本書作者有非常豐富的實際經驗可以傳授。—Martin Fowler，軟件開發(fā)大師，《重構》與《企業(yè)應用架構模式》作者這本書中充滿了對于軟件開發(fā)的真知灼見。不管你是想成為一個敏捷開發(fā)人員，還是想提高自己的技能，本書都同樣有用。我一直在期盼著這本書，它沒有令我失望?！狤rich Gamma，軟件開發(fā)大師，《設計模式》作者在本書中，Bob Martin向我們展示了他作為開發(fā)大師以及教育家的天賦。書中都是重要的經驗，并且閱讀起來就是一種享受。他以其務實的判斷力和令人愉悅的風格給我們以啟迪。—Craig Larman，《UML和模式應用》作者這也許是第一部把敏捷方法、模式和最新的軟件開發(fā)基本原則完美結合在一起的圖書。當Bob Martin發(fā)言時，我們最好洗耳恭聽?！狫ohn Vlissides，軟件開發(fā)大師，《設計模式》作者本書作者成功地實現了目標，這要歸功于他三十多年的開發(fā)經驗?！緯鴮υO計模式的闡述使我難以釋卷?！狣iomidis Spinellis，軟件開發(fā)大師，《高質量程序設計藝術》作者以我之見，本書不愧為最佳面向對象設計圖書。—John Wetherbie，JavaRanch.com

名人推薦

本書是對敏捷編程和敏捷原則最全面和最有價值的介紹……本書絕對是所有.NET程序員必讀之作。 ——Jesse Liberty，微軟資深技術專家 我最喜愛的技術作家Robert Martin善于通過實踐展示技術，讓讀者能夠以自己喜歡的方式逐步理解…請把Bob大叔當做你在敏捷世界里的導師。 ——Chris Sells，.NET資深技術專家，微軟“軟件傳奇人物” 前幾天，我找到了記有我對Bob大叔第一印象的備忘錄。上面寫著“優(yōu)秀的對象思想”。你手中的這本書就是能讓你受益終生的“優(yōu)秀的對象思想”。 ——KentBeck，軟件開發(fā)大師，極限編程之父，設計模式先驅。 我期待這本書已經很久了，關于如何去掌握我們的行業(yè)技技能，本書作者有非常豐富的實際經驗可以傳授。 ——Martin Fowler，軟件開發(fā)大師，《重構》與《企業(yè)應用架構模式》作者 本書中充滿了對于軟件開發(fā)的真知灼見。不管你是想成為一個敏捷開發(fā)人員，還是想提高自己的技能，本書都同樣有用。我一直在期盼著這本書，它沒有令我失望。 ＿Erich Gamma，軟件開發(fā)大師，《設計模式》作者 在本書中，Bob Martin向我們展示了他作為開發(fā)大師以及教育家的天賦。書中都是重要的經驗，并且閱讀起來就是一種享受。他以其務實的判斷力和令人愉悅的風格給我們以啟迪。 ——Craig Larman，《UMＬ和模式應用》作者 這也許是第一部把敏捷方法、模式和最新的軟件開發(fā)基本原則完美結合在一起的圖書。當Bob Martin發(fā)言時，我們最好洗耳恭聽。 ——John Vlissides，軟件開發(fā)大師，《設計模式》作者 本書作者成功地實現了目標，這耍歸功于他三十多年的開發(fā)經驗?！緯鴮υO計模式的闡述使我難以釋卷。 ——Diomidis Spinellis，軟件開發(fā)大師，《高質量程序設計藝術》作者 以我之見，本書不愧為最佳面向對象設計圖書。 ——John Wetherbie，JavaRanch.com

圖書封面

圖書標簽Tags

無

評論、評分、閱讀與下載

---

    敏捷軟件開發(fā) PDF格式下載

---