第1章 麵嚮對象：讓軟件開發變輕鬆的技術 1
1.1　麵嚮對象是軟件開發的綜閤技術　3
1.2　以對象為中心編寫軟件的開發方法　4
1.3　從編程語言演化為綜閤技術　4
1.4　在混亂的狀態下去理解，就會覺得很難　5
1.5　混亂之一：術語洪流　6
1.6　混亂之二：比喻濫用　7
1.7　混亂之三：“一切都是對象”綜閤徵　8
1.8　三種混亂增大瞭理解的難度　9
1.9　因為不理解，所以纔感覺神秘　10
1.10　消除這三種混亂，就能看到麵嚮對象的真麵目　10
1.11　本書的構成　11
第2章 似是而非：麵嚮對象與現實世界　13
2.1　如果隻理解概念，就容易混亂　15
2.2　對照現實世界介紹麵嚮對象　15
2.3　類指類型，實例指具體的物　16
2.4　多態讓消息的發送方法通用　18
2.5　繼承對共同點和不同點進行係統的分類和整理　20
2.6　麵嚮對象和現實世界是似是而非的　22
2.7　現實世界的人和物不是由類創建的　23
2.8　現實世界的人和物並不隻是根據消息來行動　24
2.9　明確定義為編程結構　25
2.10　軟件並不會直接錶示現實世界　25
2.11　與現實世界的相似擴大瞭可能性　26
專欄　對象的另一麵
成為潮詞的麵嚮對象　27
第3章　理解OOP：編程語言的曆史　29
3.1　OOP的齣現具有必然性　31
3.2　最初使用機器語言編寫程序　31
3.3　編程語言的第 一步是匯編語言　32
3.4　高級語言的發明使程序更加接近人類　33
3.5　重視易懂性的結構化編程　34
3.6　提高子程序的獨立性，強化可維護性　35
3.7　實現無GOTO編程的結構化語言　38
3.8　進化方嚮演變為重視可維護性和可重用性　39
3.9　沒有解決全局變量問題和可重用性差的問題　41
專欄　編程往事
COBOL編譯器的雞和蛋的問題　45
第4章　麵嚮對象編程技術：去除冗餘、進行整理　47
4.1　OOP具有結構化語言所沒有的三種結構　49
4.2　OOP的結構會根據編程語言的不同而略有差異　51
4.3　三大要素之一：類具有的三種功能　51
4.4　類的功能之一：匯總　52
4.5　類的功能之二：隱藏　55
4.6　類的功能之三：創建很多個　58
4.7　實例變量是限定訪問範圍的全局變量　61
4.8　三大要素之二：實現調用端公用化的多態　63
4.9　三大要素之三：去除類的重復定義的繼承　67
4.10　對三大要素的總結　70
4.11　通過嵌入類型使程序員的工作變輕鬆　71
4.12　將類作為類型使用　72
4.13　編程語言“退化”瞭嗎　74
4.14　更先進的OOP結構　74
4.15　進化的OOP結構之一：包　75
4.16　進化的OOP結構之二：異常　76
4.17　進化的OOP結構之三：垃圾迴收　78
4.18　對OOP進化的總結　80
4.19　決心決定OOP的生死　81
第5章　理解內存結構：程序員的基本素養　83
5.1　理解OOP程序的運行機製　85
5.2　兩種運行方式：編譯器與解釋器　85
5.3　解釋、運行中間代碼的虛擬機　88
5.4　CPU同時運行多個綫程　89
5.5　使用靜態區、堆區和棧區進行管理　91
5.6　OOP的特徵在於內存的用法　94
5.7　每個類隻加載一個類信息　95
5.8　每次創建實例都會使用堆區　96
5.9　在變量中存儲實例的指針　97
5.10　復製存儲實例的變量時要多加注意　99
5.11　多態讓不同的類看起來一樣　103
5.12　根據繼承的信息類型的不同，內存配置也不同　105
5.13　孤立的實例由垃圾迴收處理　107
專欄　編程往事
OOP中dump看起來很費勁？　113
第6章　重用：OOP帶來的軟件重用和思想重用　115
6.1　OOP的優秀結構能夠促進重用　117
6.2　類庫是OOP的軟件構件群　119
6.3　標準類庫是語言規範的一部分　120
6.4　將Object類作為祖先類的繼承結構　121
6.5　框架存在各種含義　122
6.6　框架是應用程序的半成品　123
6.7　世界上可重用的軟件構件群　124
6.8　獨立性較高的構件：組件　125
6.9　設計模式是優秀的設計思想集　125
6.10　設計模式是類庫探險的路標　128
6.11　擴展到各個領域的思想的重用　129
6.12　通過類庫和模式發現的重用的好處　130
第7章　化為通用的歸納整理法的麵嚮對象　133
7.1　軟件不會直接錶示現實世界　135
7.2　應用於集閤論和職責分配　137
7.3　在上流工程中化為通用的歸納整理法　139
7.4　兩種含義引起混亂　140
7.5　分為OOP的擴展和歸納整理法進行思考　141
7.6　為何化為瞭通用的歸納整理法　142
專欄　對象的另一麵
語言在先，還是概念在先　143
第8章　UML：查看無形軟件的工具　145
8.1　UML是錶示軟件功能和結構的圖形的繪製方法　147
8.2　UML有13種圖形　148
8.3　UML的使用方法大緻分為三種　150
8.4　UML的使用方法之一：錶示程序結構和動作　151
8.5　類圖錶示OOP程序的結構　151
8.6　使用時序圖和通信圖錶示動作　154
8.7　UML的使用方法之二：錶示歸納整理法的成果　156
8.8　使用類圖錶示根據集閤論進行整理的結果　157
8.9　錶示職責分配的時序圖和通信圖　160
8.10　UML的使用方法之三：錶示非麵嚮對象　163
8.11　使用用例圖錶示交給計算機的工作　163
8.12　使用活動圖錶示工作流程　164
8.13　使用狀態機圖錶示狀態的變化　165
8.14　彌補自然語言和計算機語言缺點的“語言”　166
第9章　建模：填補現實世界和軟件之間的溝壑　171
9.1　現實世界和軟件之間存在溝壑　173
9.2　計算機擅長固定工作和記憶工作　174
9.3　通過業務分析、需求定義和設計來填補溝壑　175
9.4　建模是順利推進這3個階段的工作的技術　176
9.5　應用程序不同，建模的內容也不一樣　177
9.6　業務應用程序記錄現實中的事情　178
9.7　對圖書館的藉閱業務進行建模　179
9.8　使用用例圖來錶示圖書館業務　181
9.9　用概念模型錶示圖書館係統的信息　183
9.10　業務應用程序中隻有數據是無縫的　184
9.11　嵌入式軟件替換現實世界的工作　186
9.12　嵌入式軟件中設備的研究開發很重要　187
9.13　使用狀態機圖來錶示全自動工作的情形　189
9.14　嵌入式軟件一直執行單調的工作　190
9.15　建模蘊含著軟件開發的樂趣　191
第10章 麵嚮對象設計：擬人化和職責分配　195
10.1　設計的目標範圍很廣　197
10.2　相比運行效率，現在更重視可維護性和可重用性　198
10.3　設計目標之一：去除重復　199
10.4　設計目標之二：提高構件的獨立性　200
10.5　提高構件獨立性的訣竅　202
10.6　設計目標之三：避免依賴關係發生循環　203
10.7　麵嚮對象設計的“感覺”是擬人化和職責分配　205
10.8　進行瞭職責分配的軟件創建的奇妙世界　206
第11章 衍生：敏捷開發和TDD　211
11.1　僅靠技術和技術竅門，軟件開發並不會成功　213
11.2　係統地匯總瞭作業步驟和成果的開發流程　214
11.3　限製修改的瀑布式開發流程　214
11.4　瀑布式開發流程的極限　215
11.5　靈活響應變化的迭代式開發流程　216
11.6　RUP按時間分解和管理開發　217
11.7　打破諸多限製的XP　219
11.8　快速編寫優秀軟件的敏捷宣言　221
11.9　支持敏捷開發的實踐　222
11.10　先編寫測試代碼，一邊運行一邊開發的測試驅動開發　222
11.11　在程序完成後改善運行代碼的重構　224
11.12　經常進行係統整閤的持續集成　225
11.13　敏捷開發和TDD源於麵嚮對象　226
11.14　不存在最好的開發流程　227
專欄　編程往事
過去不被允許的XP　231
第12章 熟練掌握麵嚮對象　233
12.1　麵嚮對象這一強大概念是原動力　235
12.2　時代追上瞭麵嚮對象　236
12.3　麵嚮對象的熱潮不會結束　237
12.4　將麵嚮對象作為工具熟練掌握　238
12.5　享受需要動腦的軟件開發　239
第13章 函數式語言是怎樣工作的　241
13.1　麵嚮對象的“下一代”開發技術　243
13.2　函數式語言的7個特徵　244
13.3　特徵1：使用函數編寫程序　244
13.4　特徵2：所有錶達式都返迴值　246
13.5　特徵3：將函數作為值進行處理　250
13.6　特徵4：可以靈活組閤函數和參數　252
13.7　特徵5：沒有副作用　256
13.8　特徵6：使用分類和遞歸來編寫循環處理　261
13.9　特徵7：編譯器自動進行類型推斷　266
13.10　對7個特徵的總結　270
13.11　函數式語言的分類　271
13.12　函數式語言的優勢　271
13.13　函數式語言的課題　272
13.14　函數式語言和麵嚮對象的關係　273
13.15　函數式語言會普及嗎　275
後記　279
緻謝　280
· · · · · · (收起)