大規(guī)模C++軟件開發(fā) 卷1：過程與架構(gòu)

第0章 動機 1
0.1 目標：進度更快、產(chǎn)品更好、預算更低 1
0.2 應用軟件與庫軟件 3
0.3 協(xié)作式軟件與可復用軟件 8
0.4 層次化可復用軟件 12
0.5 易延展軟件與穩(wěn)定軟件 16
0.6 物理設計的關(guān)鍵作用 24
0.7 物理形式統(tǒng)一的軟件：組件 25
0.8 對層次化復用的量化：一個類比 32
0.9 軟件資本 51
0.10 增大投入 57
0.11 保持警覺 62
0.12 小結(jié) 65

第 1章 編譯器、連接器和組件 70
1.1 知識就是力量：細節(jié)決定成敗 70
1.1.1 “Hello World!” 70
1.1.2 創(chuàng)建C++程序 71
1.1.3 頭文件的作用 72
1.2 C++程序的編譯和連接 73
1.2.1 構(gòu)建流程：編譯器和連接器的使用 73
1.2.2 目標文件（.o）的經(jīng)典原子性 77
1.2.3 .o文件中的節(jié)和弱符號 79
1.2.4 靜態(tài)庫 79
1.2.5 “單例”注冊表的例子 81
1.2.6 庫間依賴 84
1.2.7 連接順序和構(gòu)建時行為 87
1.2.8 連接順序和運行時行為 87
1.2.9 共享（動態(tài)連接）庫 88
1.3 聲明、定義和連結(jié) 88
1.3.1 聲明與定義 88
1.3.2 （邏輯的）連結(jié)與（物理的）連接 92
1.3.3 需要了解連接工具 92
1.3.4 物理“連結(jié)”的另一種定義：綁結(jié) 92
1.3.5 連接器運作的更多細節(jié) 93
1.3.6 對一些需要全程序范圍內(nèi)地址唯一的實體的介紹 94
1.3.7 客戶編譯器需要看到定義的源代碼的構(gòu)件 96
1.3.8 聲明并不一定要帶上定義才能起作用 97
1.3.9 客戶編譯器通常需要看到類定義 97
1.3.10 客戶編譯器必須看到定義的源代碼的其他實體 98
1.3.11 枚舉具有外連結(jié)，但又會怎樣 98
1.3.12 內(nèi)聯(lián)函數(shù)略有特殊 99
1.3.13 函數(shù)模板和類模板 99
1.3.14 函數(shù)模板和顯式特化 100
1.3.15 類模板及其偏特化 104
1.3.16 extern模板 106
1.3.17 用工具來理解單一定義規(guī)則和綁結(jié) 108
1.3.18 命名空間 108
1.3.19 對const實體默認連結(jié)的闡釋 109
1.3.20 本節(jié)小結(jié) 109
1.4 頭文件 111
1.5 包含指令和包含保護符 118
1.5.1 包含指令 118
1.5.2 內(nèi)置的包含保護符 119
1.5.3 外置的包含保護符（已廢棄） 121
1.6 從.h/.cpp文件對到組件 123
1.6.1 組件特性1 123
1.6.2 組件特性2 125
1.6.3 組件特性3 126
1.7 符號和術(shù)語 128
1.7.1 概要 128
1.7.2 Is-A邏輯關(guān)系 130
1.7.3 Uses-In-The-Interface邏輯關(guān)系 130
1.7.4 Uses-In-The-Implementation邏輯關(guān)系 131
1.7.5 Uses-In-Name-Only邏輯關(guān)系和協(xié)議類 133
1.7.6 In-Structure-Only（ISO）協(xié)作式邏輯關(guān)系 135
1.7.7 受約束模板和接口繼承的相似之處 136
1.7.8 受約束模板和接口繼承的不同之處 137
1.7.9 3種“繼承型”關(guān)系各有所長 138
1.7.10 給模板的類型約束編寫注釋 139
1.7.11 本節(jié)小結(jié) 140
1.8 Depends-On關(guān)系 141
1.9 隱含依賴 144
1.10 層級編號 149
1.11 抽取實際的依賴 151
組件特性4 152
1.12 小結(jié) 153

第 2章 打包和設計規(guī)則 159
2.1 觀全貌 159
2.2 物理聚合 161
2.2.1 物理聚合的一般定義 161
2.2.2 物理聚合譜的小端 162
2.2.3 物理聚合譜的大端 162
2.2.4 聚合的概念原子性 163
2.2.5 聚合依賴的廣義定義 163
2.2.6 架構(gòu)顯著性 164
2.2.7 一般發(fā)布單元的架構(gòu)顯著性 164
2.2.8 發(fā)布單元中具有架構(gòu)顯著性的部分 164
2.2.9 發(fā)布單元的什么部分不是架構(gòu)顯著的 164
2.2.10 組件“自然地”具有架構(gòu)顯著性 164
2.2.11 組件必須是一對.h/.cpp文件嗎 165
2.2.12 何時不宜寫成一對.h/.cpp文件 165
2.2.13 對.cpp文件的劃分僅是組織上的改變 165
2.2.14 實體清單和可容許依賴 165
2.2.15 對可容許依賴的包絡的表達需求 167
2.2.16 物理層次需平衡得當 167
2.2.17 不僅要層次化，而且要講究平衡 168
2.2.18 物理聚合超過3級即算過多 169
2.2.19 即使是大型系統(tǒng)，3級也已足夠 170
2.2.20 發(fā)布單元總有2級或3級的物理聚合 171
2.2.21 平衡得當?shù)?級聚合就已足夠 171
2.2.22 發(fā)布單元應該是最為架構(gòu)顯著的 171
2.2.23 架構(gòu)顯著的名稱必須唯一 171
2.2.24 不要出現(xiàn)循環(huán)物理依賴 172
2.2.25 本節(jié)小結(jié) 173
2.3 邏輯連貫和物理連貫 173
2.4 邏輯名稱銜接和物理名稱銜接 175
2.4.1 過去對命名空間污染的應對措施 175
2.4.2 名稱務必唯一，銜接的命名有益于人 175
2.4.3 既不銜接又不有助記憶的命名荒謬至極 176
2.4.4 需要相互銜接的名稱 177
2.4.5 過去/現(xiàn)在對包的定義 177
2.4.6 使用點就應足夠敲定位置 177
2.4.7 專有軟件須有企業(yè)級命名空間 182
2.4.8 邏輯構(gòu)件署名應錨定于其組件 182
2.4.9 在包級命名空間的作用域中只有類、結(jié)構(gòu)體和自由運算符 183
2.4.10 包的前綴命名不僅僅是編程風格 189
2.4.11 包前綴即其所在包組名 192
2.4.12 using指令和聲明往往是壞主意 193
2.4.13 本節(jié)小結(jié) 196
2.5 組件源代碼的組織 196
2.6 組件設計規(guī)則 202
2.7 組件私有類和附屬組件 219
2.7.1 組件私有類 220
2.7.2 有幾種實現(xiàn)方案可待選擇 220
2.7.3 下劃線的約定用法 220
2.7.4 使用組件私有類的經(jīng)典案例 224
2.7.5 附屬組件 227
2.7.6 本節(jié)小結(jié) 229
2.8 包 229
2.8.1 用包來分解子系統(tǒng) 229
2.8.2 包間循環(huán)是不好的 234
2.8.3 布置、作用域和規(guī)模是首要考量 235
2.8.4 包前綴的唯一性對溝通大有裨益 236
2.8.5 本節(jié)小結(jié) 238
2.9 包組 238
2.9.1 物理聚合的第三層級 238
2.9.2 在部署時對包組的組織 245
2.9.3 在實踐中如何使用包組 245
2.9.4 去中心化的（自治的）包的創(chuàng)建 248
2.9.5 本節(jié)小結(jié) 249
2.10 包和包組的命名 249
2.10.1 平鋪直敘的包名不一定好 249
2.10.2 包組的名稱 250
2.10.3 包的名稱 250
2.10.4 本節(jié)小結(jié) 252
2.11 子包 252
2.12 遺留軟件、開源軟件和第三方軟件 254
2.13 應用 255
2.14 層次化可測試性的需求 258
2.14.1 將本書的方法論運用于細粒度的單元測試中 258
2.14.2 本節(jié)安排（還有卷2及特別是卷3的引子） 258
2.14.3 測試要能層次化地推進 258
2.14.4 測試時的局部組件依賴的相對導入 263
2.14.5 可容許的跨包的測試驅(qū)動程序依賴 266
2.14.6 盡量減少測試驅(qū)動程序?qū)ν獠凯h(huán)境的依賴 268
2.14.7 堅持統(tǒng)一（獨立）的測試驅(qū)動程序調(diào)用接口 269
2.14.8 本節(jié)小結(jié) 270
2.15 從開發(fā)到部署 271
2.15.1 不應在軟件的靈活部署方面讓步 271
2.15.2 .h和.o文件名的唯一性非常關(guān)鍵 271
2.15.3 在開發(fā)過程中軟件組織會有所變化 271
2.15.4 在全公司范圍內(nèi)讓名稱保持唯一有助于重構(gòu) 272
2.15.5 在構(gòu)建過程中軟件組織都可能有所變化 272
2.15.6 即使在正常情況下部署中仍需要靈活性 272
2.15.7 讓定制化部署成為可能是靈活性之價值的重要體現(xiàn) 273
2.15.8 頭文件中風格化呈現(xiàn)的靈活性 273
2.15.9 庫的部署方式不應架構(gòu)顯著 273
2.15.10 出于工程原因?qū)σ巡渴鸬能浖M行劃分 274
2.15.11 出于業(yè)務原因?qū)σ巡渴鸬能浖M行劃分 275
2.15.12 本節(jié)小結(jié) 276
2.16 元數(shù)據(jù) 276
2.16.1 元數(shù)據(jù)即“法令” 277
2.16.2 元數(shù)據(jù)的類型 277
2.16.3 元數(shù)據(jù)的呈現(xiàn) 281
2.16.4 本節(jié)小結(jié) 282
2.17 小結(jié) 283

第3章 物理設計和分解 290
3.1 從物理的角度思考 290
3.1.1 純經(jīng)典的（邏輯的）軟件設計是幼稚的 291
3.1.2 組件充當細粒度的模塊 291
3.1.3 軟件的設計空間是有方向性的 291
3.1.4 軟件有其絕對位置 292
3.1.5 并置與否的準則應該看本質(zhì)，不應流于表面 293
3.1.6 不規(guī)整的非初等功能搜尋十分麻煩 293
3.1.7 包的作用域是一項重要的設計考量 293
3.1.8 禁止循環(huán)物理依賴帶來的一些限制 295
3.1.9 對友元的約束有意排除了某些邏輯設計 297
3.1.10 一個有正當理由要求包裝的 案例 297
3.1.11 本節(jié)小結(jié) 302
3.2 避免糟糕的物理模塊化 303
3.2.1 有很多糟糕的模塊化準則，語法是其中之一 303
3.2.2 將用途廣泛的軟件分解并加入庫中非常重要 303
3.2.3 迫于壓力未能維持應用/庫的模塊化 303
3.2.4 可復用組件的持續(xù)降級至關(guān)重要 304
3.2.5 對應用開發(fā)者而言，物理依賴不是實現(xiàn)細節(jié) 305
3.2.6 迭代器有助于減少初等功能的開發(fā)量 309
3.2.7 既要最小也要初等：實用結(jié)構(gòu)體 309
3.2.8 總結(jié)性示例：封裝型多邊形類接口 309
3.2.9 語義與語法作為模塊化準則 322
3.2.10 本節(jié)小結(jié) 323
3.3 邏輯相近的事物在物理上應分組在一起 324
3.3.1 類并置的4個明確準則 324
3.3.2 組件之上的并置 327
3.3.3 何時讓輔助類供其組件私用 327
3.3.4 模板特化的并置 329
3.3.5 附屬組件的使用 329
3.3.6 將緊密的相互協(xié)作并置于單個發(fā)布單元中 330
3.3.7 計算天數(shù)的示例 330
3.3.8 最后的示例：單線程引用計數(shù)型函子 336
3.3.9 本節(jié)小結(jié) 344
3.4 避免循環(huán)的連接時依賴 345
3.5 層級劃分技術(shù) 351
3.5.1 經(jīng)典層級劃分技術(shù) 351
3.5.2 升級 352
3.5.3 降級 357
3.5.4 不透明指針 359
3.5.5 啞數(shù)據(jù) 365
3.5.6 冗余 367
3.5.7 回調(diào) 371
3.5.8 管理器類 389
3.5.9 分解 391
3.5.10 升級封裝 392
3.5.11 本節(jié)小結(jié) 407
3.6 避免過度的連接時依賴 408
3.6.1 起初分解妥當?shù)娜掌陬悤S時間退化 408
3.6.2 將工作日功能添加到日期類中（壞主意） 414
3.6.3 提供一個物理上整塊式的平臺適配器（壞主意） 415
3.6.4 本節(jié)小結(jié) 418
3.7 橫展架構(gòu)與分層架構(gòu) 418
3.7.1 另一個與建筑業(yè)的類比 419
3.7.2 （經(jīng)典的）分層架構(gòu) 419
3.7.3 對純組合式設計加以改進 421
3.7.4 最小化累積組件依賴度 421
3.7.5 基于繼承的橫展架構(gòu) 424
3.7.6 橫展架構(gòu)與分層架構(gòu)的測試 427
3.7.7 本節(jié)小結(jié) 427
3.8 避免不當?shù)倪B接時依賴 428
3.8.1 不當?shù)奈锢硪蕾?428
3.8.2 在單一技術(shù)上“押注”（壞主意） 431
3.8.3 本節(jié)小結(jié) 436
3.9 確保物理互操作性 436
3.9.1 妨礙層次化的復用是壞主意 436
3.9.2 領(lǐng)域特定的條件編譯是壞主意 437
3.9.3 在庫組件中的應用特定的依賴是壞主意 439
3.9.4 約束并排型復用是壞主意 440
3.9.5 防止故意的濫用不是目的 441
3.9.6 讓組件侵占全局資源是壞主意 441
3.9.7 隱藏頭文件來實現(xiàn)邏輯封裝是壞主意 441
3.9.8 可復用庫中存在對不可移植軟件的依賴是壞主意 443
3.9.9 將潛在可復用軟件隱藏起來是壞主意 446
3.9.10 本節(jié)小結(jié) 447
3.10 避免不必要的編譯時依賴 447
3.10.1 封裝不能杜絕編譯時耦合 447
3.10.2 共享枚舉和編譯時耦合 449
3.10.3 C++中的編譯時耦合比C語言中更為普遍 451
3.10.4 避免不必要的編譯時耦合 451
3.10.5 避免編譯時耦合的益處及真實示例 454
3.10.6 本節(jié)小結(jié) 458
3.11 架構(gòu)隔離技術(shù) 458
3.11.1 封裝與隔離的形式化定義 459
3.11.2 用組件的概念闡釋封裝與 隔離 459
3.11.3 整體隔離與部分隔離 460
3.11.4 架構(gòu)顯著的整體隔離技術(shù) 461
3.11.5 純抽象接口（協(xié)議）類 461
3.11.6 完全隔離型具體包裝器 組件 467
3.11.7 過程接口 471
3.11.8 隔離和動態(tài)加載庫 484
3.11.9 面向服務的架構(gòu) 484
3.11.10 本節(jié)小結(jié) 485
3.12 用組件進行設計 485
3.12.1 原先陳述的“需求” 485
3.12.2 實際（外延）的需求 486
3.12.3 用C++類型表示日期值 487
3.12.4 確定今天的日期值 494
3.12.5 確定給定日期值是否為工作日 496
3.12.6 解析和格式化功能 508
3.12.7 值的傳輸與持久化 510
3.12.8 債券計息日數(shù)慣例 510
3.12.9 日期數(shù)學 510
3.12.10 日期和日歷實用件 513
3.12.11 充實分解透徹的實現(xiàn) 515
3.12.12 本節(jié)小結(jié) 527
3.13 小結(jié) 529
結(jié)論 536
參考文獻 538