掃一掃
關注中圖網
官方微博
本類五星書更多>
-
>
全國計算機等級考試最新真考題庫模擬考場及詳解·二級MSOffice高級應用
-
>
決戰行測5000題(言語理解與表達)
-
>
軟件性能測試.分析與調優實踐之路
-
>
第一行代碼Android
-
>
JAVA持續交付
-
>
EXCEL最強教科書(完全版)(全彩印刷)
-
>
深度學習
大規模C++軟件開發 卷1:過程與架構 版權信息
- ISBN：9787115609779
- 條形碼：9787115609779 ; 978-7-115-60977-9
- 裝幀：平裝-膠訂
- 冊數：暫無
- 重量：暫無
- 所屬分類：>>
大規模C++軟件開發 卷1:過程與架構 本書特色
·熱銷圖書作者約翰·拉科斯（John Lakos）新作，將其在C 領域超過30年的經驗匯聚于此，幫助讀者學到實用的知識和技能。
·大規模C 編程全解，內容豐富。從設計理念到開發過程，從方法論到技術工具，無一不包，讓讀者深入了解大規模C 軟件開發的各個方面。
·不僅介紹理論知識，還通過具體示例展示了開發實踐。在實際開發應用中，提高開發效率和代碼質量。
·系統介紹設計概念，為大規模的項目奠定基礎。無論你是C 初學者還是經驗豐富的開發者，都會受益匪淺。
大規模C++軟件開發 卷1:過程與架構 內容簡介
本書通過具體示例演示大規模C++開發的基本設計設想，為各種規模的項目奠定基礎，并演示成功進行大規模實際開發所需的過程、方法、技術和工具。通過閱讀本書，讀者可以逐步改變自己的設計和開發方法。本書旨在使用軟件從業人員熟悉的C++構件來解決現實問題，同時確定（并激發）現代C++替代方案。作者利用超過30年的構建大規模、關鍵任務的企業系統的實踐經驗，展示了如何創建和增長軟件資本。
本書專為有經驗的C++軟件開發者和系統設計師編寫，從事大型軟件開發工作的架構師或項目負責人等也可以通過閱讀本書解決實際工作中的問題。
大規模C++軟件開發 卷1:過程與架構 目錄
第0章 動機 1
0.1 目標：進度更快、產品更好、預算更低 1
0.2 應用軟件與庫軟件 3
0.3 協作式軟件與可復用軟件 8
0.4 層次化可復用軟件 12
0.5 易延展軟件與穩定軟件 16
0.6 物理設計的關鍵作用 24
0.7 物理形式統一的軟件：組件 25
0.8 對層次化復用的量化：一個類比 32
0.9 軟件資本 51
0.10 增大投入 57
0.11 保持警覺 62
0.12 小結 65
第 1章 編譯器、連接器和組件 70
1.1 知識就是力量：細節決定成敗 70
1.1.1 “Hello World!” 70
1.1.2 創建C 程序 71
1.1.3 頭文件的作用 72
1.2 C 程序的編譯和連接 73
1.2.1 構建流程：編譯器和連接器的使用 73
1.2.2 目標文件（.o）的經典原子性 77
1.2.3 .o文件中的節和弱符號 79
1.2.4 靜態庫 79
1.2.5 “單例”注冊表的例子 81
1.2.6 庫間依賴 84
1.2.7 連接順序和構建時行為 87
1.2.8 連接順序和運行時行為 87
1.2.9 共享（動態連接）庫 88
1.3 聲明、定義和連結 88
1.3.1 聲明與定義 88
1.3.2 （邏輯的）連結與（物理的）連接 92
1.3.3 需要了解連接工具 92
1.3.4 物理“連結”的另一種定義：綁結 92
1.3.5 連接器運作的更多細節 93
1.3.6 對一些需要全程序范圍內地址唯一的實體的介紹 94
1.3.7 客戶編譯器需要看到定義的源代碼的構件 96
1.3.8 聲明并不一定要帶上定義才能起作用 97
1.3.9 客戶編譯器通常需要看到類定義 97
1.3.10 客戶編譯器必須看到定義的源代碼的其他實體 98
1.3.11 枚舉具有外連結，但又會怎樣 98
1.3.12 內聯函數略有特殊 99
1.3.13 函數模板和類模板 99
1.3.14 函數模板和顯式特化 100
1.3.15 類模板及其偏特化 104
1.3.16 extern模板 106
1.3.17 用工具來理解單一定義規則和綁結 108
1.3.18 命名空間 108
1.3.19 對const實體默認連結的闡釋 109
1.3.20 本節小結 109
1.4 頭文件 111
1.5 包含指令和包含保護符 118
1.5.1 包含指令 118
1.5.2 內置的包含保護符 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 符號和術語 128
1.7.1 概要 128
1.7.2 Is-A邏輯關系 130
1.7.3 Uses-In-The-Interface邏輯關系 130
1.7.4 Uses-In-The-Implementation邏輯關系 131
1.7.5 Uses-In-Name-Only邏輯關系和協議類 133
1.7.6 In-Structure-Only（ISO）協作式邏輯關系 135
1.7.7 受約束模板和接口繼承的相似之處 136
1.7.8 受約束模板和接口繼承的不同之處 137
1.7.9 3種“繼承型”關系各有所長 138
1.7.10 給模板的類型約束編寫注釋 139
1.7.11 本節小結 140
1.8 Depends-On關系 141
1.9 隱含依賴 144
1.10 層級編號 149
1.11 抽取實際的依賴 151
組件特性4 152
1.12 小結 153
第 2章 打包和設計規則 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 架構顯著性 164
2.2.7 一般發布單元的架構顯著性 164
2.2.8 發布單元中具有架構顯著性的部分 164
2.2.9 發布單元的什么部分不是架構顯著的 164
2.2.10 組件“自然地”具有架構顯著性 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 即使是大型系統，3級也已足夠 170
2.2.20 發布單元總有2級或3級的物理聚合 171
2.2.21 平衡得當的3級聚合就已足夠 171
2.2.22 發布單元應該是*為架構顯著的 171
2.2.23 架構顯著的名稱必須唯一 171
2.2.24 不要出現循環物理依賴 172
2.2.25 本節小結 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 過去/現在對包的定義 177
2.4.6 使用點就應足夠敲定位置 177
2.4.7 專有軟件須有企業級命名空間 182
2.4.8 邏輯構件署名應錨定于其組件 182
2.4.9 在包級命名空間的作用域中只有類、結構體和自由運算符 183
2.4.10 包的前綴命名不僅僅是編程風格 189
2.4.11 包前綴即其所在包組名 192
2.4.12 using指令和聲明往往是壞主意 193
2.4.13 本節小結 196
2.5 組件源代碼的組織 196
2.6 組件設計規則 202
2.7 組件私有類和附屬組件 219
2.7.1 組件私有類 220
2.7.2 有幾種實現方案可待選擇 220
2.7.3 下劃線的約定用法 220
2.7.4 使用組件私有類的經典案例 224
2.7.5 附屬組件 227
2.7.6 本節小結 229
2.8 包 229
2.8.1 用包來分解子系統 229
2.8.2 包間循環是不好的 234
2.8.3 布置、作用域和規模是首要考量 235
2.8.4 包前綴的唯一性對溝通大有裨益 236
2.8.5 本節小結 238
2.9 包組 238
2.9.1 物理聚合的第三層級 238
2.9.2 在部署時對包組的組織 245
2.9.3 在實踐中如何使用包組 245
2.9.4 去中心化的（自治的）包的創建 248
2.9.5 本節小結 249
2.10 包和包組的命名 249
2.10.1 平鋪直敘的包名不一定好 249
2.10.2 包組的名稱 250
2.10.3 包的名稱 250
2.10.4 本節小結 252
2.11 子包 252
2.12 遺留軟件、開源軟件和第三方軟件 254
2.13 應用 255
2.14 層次化可測試性的需求 258
2.14.1 將本書的方法論運用于細粒度的單元測試中 258
2.14.2 本節安排（還有卷2及特別是卷3的引子） 258
2.14.3 測試要能層次化地推進 258
2.14.4 測試時的局部組件依賴的相對導入 263
2.14.5 可容許的跨包的測試驅動程序依賴 266
2.14.6 盡量減少測試驅動程序對外部環境的依賴 268
2.14.7 堅持統一（獨立）的測試驅動程序調用接口 269
2.14.8 本節小結 270
2.15 從開發到部署 271
2.15.1 不應在軟件的靈活部署方面讓步 271
2.15.2 .h和.o文件名的唯一性非常關鍵 271
2.15.3 在開發過程中軟件組織會有所變化 271
2.15.4 在全公司范圍內讓名稱保持唯一有助于重構 272
2.15.5 在構建過程中軟件組織都可能有所變化 272
2.15.6 即使在正常情況下部署中仍需要靈活性 272
2.15.7 讓定制化部署成為可能是靈活性之價值的重要體現 273
2.15.8 頭文件中風格化呈現的靈活性 273
2.15.9 庫的部署方式不應架構顯著 273
2.15.10 出于工程原因對已部署的軟件進行劃分 274
2.15.11 出于業務原因對已部署的軟件進行劃分 275
2.15.12 本節小結 276
2.16 元數據 276
2.16.1 元數據即“法令” 277
2.16.2 元數據的類型 277
2.16.3 元數據的呈現 281
2.16.4 本節小結 282
2.17 小結 283
第3章 物理設計和分解 290
3.1 從物理的角度思考 290
3.1.1 純經典的（邏輯的）軟件設計是幼稚的 291
3.1.2 組件充當細粒度的模塊 291
3.1.3 軟件的設計空間是有方向性的 291
3.1.4 軟件有其絕對位置 292
3.1.5 并置與否的準則應該看本質，不應流于表面 293
3.1.6 不規整的非初等功能搜尋十分麻煩 293
3.1.7 包的作用域是一項重要的設計考量 293
3.1.8 禁止循環物理依賴帶來的一些限制 295
3.1.9 對友元的約束有意排除了某些邏輯設計 297
3.1.10 一個有正當理由要求包裝的 案例 297
3.1.11 本節小結 302
3.2 避免糟糕的物理模塊化 303
3.2.1 有很多糟糕的模塊化準則，語法是其中之一 303
3.2.2 將用途廣泛的軟件分解并加入庫中非常重要 303
3.2.3 迫于壓力未能維持應用/庫的模塊化 303
3.2.4 可復用組件的持續降級至關重要 304
3.2.5 對應用開發者而言，物理依賴不是實現細節 305
3.2.6 迭代器有助于減少初等功能的開發量 309
3.2.7 既要*小也要初等：實用結構體 309
3.2.8 總結性示例：封裝型多邊形類接口 309
3.2.9 語義與語法作為模塊化準則 322
3.2.10 本節小結 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 將緊密的相互協作并置于單個發布單元中 330
3.3.7 計算天數的示例 330
3.3.8 *后的示例：單線程引用計數型函子 336
3.3.9 本節小結 344
3.4 避免循環的連接時依賴 345
3.5 層級劃分技術 351
3.5.1 經典層級劃分技術 351
3.5.2 升級 352
3.5.3 降級 357
3.5.4 不透明指針 359
3.5.5 啞數據 365
3.5.6 冗余 367
3.5.7 回調 371
3.5.8 管理器類 389
3.5.9 分解 391
3.5.10 升級封裝 392
3.5.11 本節小結 407
3.6 避免過度的連接時依賴 408
3.6.1 起初分解妥當的日期類會隨時間退化 408
3.6.2 將工作日功能添加到日期類中（壞主意） 414
3.6.3 提供一個物理上整塊式的平臺適配器（壞主意） 415
3.6.4 本節小結 418
3.7 橫展架構與分層架構 418
3.7.1 另一個與建筑業的類比 419
3.7.2 （經典的）分層架構 419
3.7.3 對純組合式設計加以改進 421
3.7.4 *小化累積組件依賴度 421
3.7.5 基于繼承的橫展架構 424
3.7.6 橫展架構與分層架構的測試 427
3.7.7 本節小結 427
3.8 避免不當的連接時依賴 428
3.8.1 不當的物理依賴 428
3.8.2 在單一技術上“押注”（壞主意） 431
3.8.3 本節小結 436
3.9 確保物理互操作性 436
3.9.1 妨礙層次化的復用是壞主意 436
3.9.2 領域特定的條件編譯是壞主意 437
3.9.3 在庫組件中的應用特定的依賴是壞主意 439
3.9.4 約束并排型復用是壞主意 440
3.9.5 防止故意的濫用不是目的 441
3.9.6 讓組件侵占全局資源是壞主意 441
3.9.7 隱藏頭文件來實現邏輯封裝是壞主意 441
3.9.8 可復用庫中存在對不可移植軟件的依賴是壞主意 443
3.9.9 將潛在可復用軟件隱藏起來是壞主意 446
3.9.10 本節小結 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 本節小結 458
3.11 架構隔離技術 458
3.11.1 封裝與隔離的形式化定義 459
3.11.2 用組件的概念闡釋封裝與 隔離 459
3.11.3 整體隔離與部分隔離 460
3.11.4 架構顯著的整體隔離技術 461
3.11.5 純抽象接口（協議）類 461
3.11.6 完全隔離型具體包裝器 組件 467
3.11.7 過程接口 471
3.11.8 隔離和動態加載庫 484
3.11.9 面向服務的架構 484
3.11.10 本節小結 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 債券計息日數慣例 510
3.12.9 日期數學 510
3.12.10 日期和日歷實用件 513
3.12.11 充實分解透徹的實現 515
3.12.12 本節小結 527
3.13 小結 529
結論 536
參考文獻 538
0.1 目標：進度更快、產品更好、預算更低 1
0.2 應用軟件與庫軟件 3
0.3 協作式軟件與可復用軟件 8
0.4 層次化可復用軟件 12
0.5 易延展軟件與穩定軟件 16
0.6 物理設計的關鍵作用 24
0.7 物理形式統一的軟件：組件 25
0.8 對層次化復用的量化：一個類比 32
0.9 軟件資本 51
0.10 增大投入 57
0.11 保持警覺 62
0.12 小結 65
第 1章 編譯器、連接器和組件 70
1.1 知識就是力量：細節決定成敗 70
1.1.1 “Hello World!” 70
1.1.2 創建C 程序 71
1.1.3 頭文件的作用 72
1.2 C 程序的編譯和連接 73
1.2.1 構建流程：編譯器和連接器的使用 73
1.2.2 目標文件（.o）的經典原子性 77
1.2.3 .o文件中的節和弱符號 79
1.2.4 靜態庫 79
1.2.5 “單例”注冊表的例子 81
1.2.6 庫間依賴 84
1.2.7 連接順序和構建時行為 87
1.2.8 連接順序和運行時行為 87
1.2.9 共享（動態連接）庫 88
1.3 聲明、定義和連結 88
1.3.1 聲明與定義 88
1.3.2 （邏輯的）連結與（物理的）連接 92
1.3.3 需要了解連接工具 92
1.3.4 物理“連結”的另一種定義：綁結 92
1.3.5 連接器運作的更多細節 93
1.3.6 對一些需要全程序范圍內地址唯一的實體的介紹 94
1.3.7 客戶編譯器需要看到定義的源代碼的構件 96
1.3.8 聲明并不一定要帶上定義才能起作用 97
1.3.9 客戶編譯器通常需要看到類定義 97
1.3.10 客戶編譯器必須看到定義的源代碼的其他實體 98
1.3.11 枚舉具有外連結，但又會怎樣 98
1.3.12 內聯函數略有特殊 99
1.3.13 函數模板和類模板 99
1.3.14 函數模板和顯式特化 100
1.3.15 類模板及其偏特化 104
1.3.16 extern模板 106
1.3.17 用工具來理解單一定義規則和綁結 108
1.3.18 命名空間 108
1.3.19 對const實體默認連結的闡釋 109
1.3.20 本節小結 109
1.4 頭文件 111
1.5 包含指令和包含保護符 118
1.5.1 包含指令 118
1.5.2 內置的包含保護符 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 符號和術語 128
1.7.1 概要 128
1.7.2 Is-A邏輯關系 130
1.7.3 Uses-In-The-Interface邏輯關系 130
1.7.4 Uses-In-The-Implementation邏輯關系 131
1.7.5 Uses-In-Name-Only邏輯關系和協議類 133
1.7.6 In-Structure-Only（ISO）協作式邏輯關系 135
1.7.7 受約束模板和接口繼承的相似之處 136
1.7.8 受約束模板和接口繼承的不同之處 137
1.7.9 3種“繼承型”關系各有所長 138
1.7.10 給模板的類型約束編寫注釋 139
1.7.11 本節小結 140
1.8 Depends-On關系 141
1.9 隱含依賴 144
1.10 層級編號 149
1.11 抽取實際的依賴 151
組件特性4 152
1.12 小結 153
第 2章 打包和設計規則 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 架構顯著性 164
2.2.7 一般發布單元的架構顯著性 164
2.2.8 發布單元中具有架構顯著性的部分 164
2.2.9 發布單元的什么部分不是架構顯著的 164
2.2.10 組件“自然地”具有架構顯著性 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 即使是大型系統，3級也已足夠 170
2.2.20 發布單元總有2級或3級的物理聚合 171
2.2.21 平衡得當的3級聚合就已足夠 171
2.2.22 發布單元應該是*為架構顯著的 171
2.2.23 架構顯著的名稱必須唯一 171
2.2.24 不要出現循環物理依賴 172
2.2.25 本節小結 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 過去/現在對包的定義 177
2.4.6 使用點就應足夠敲定位置 177
2.4.7 專有軟件須有企業級命名空間 182
2.4.8 邏輯構件署名應錨定于其組件 182
2.4.9 在包級命名空間的作用域中只有類、結構體和自由運算符 183
2.4.10 包的前綴命名不僅僅是編程風格 189
2.4.11 包前綴即其所在包組名 192
2.4.12 using指令和聲明往往是壞主意 193
2.4.13 本節小結 196
2.5 組件源代碼的組織 196
2.6 組件設計規則 202
2.7 組件私有類和附屬組件 219
2.7.1 組件私有類 220
2.7.2 有幾種實現方案可待選擇 220
2.7.3 下劃線的約定用法 220
2.7.4 使用組件私有類的經典案例 224
2.7.5 附屬組件 227
2.7.6 本節小結 229
2.8 包 229
2.8.1 用包來分解子系統 229
2.8.2 包間循環是不好的 234
2.8.3 布置、作用域和規模是首要考量 235
2.8.4 包前綴的唯一性對溝通大有裨益 236
2.8.5 本節小結 238
2.9 包組 238
2.9.1 物理聚合的第三層級 238
2.9.2 在部署時對包組的組織 245
2.9.3 在實踐中如何使用包組 245
2.9.4 去中心化的（自治的）包的創建 248
2.9.5 本節小結 249
2.10 包和包組的命名 249
2.10.1 平鋪直敘的包名不一定好 249
2.10.2 包組的名稱 250
2.10.3 包的名稱 250
2.10.4 本節小結 252
2.11 子包 252
2.12 遺留軟件、開源軟件和第三方軟件 254
2.13 應用 255
2.14 層次化可測試性的需求 258
2.14.1 將本書的方法論運用于細粒度的單元測試中 258
2.14.2 本節安排（還有卷2及特別是卷3的引子） 258
2.14.3 測試要能層次化地推進 258
2.14.4 測試時的局部組件依賴的相對導入 263
2.14.5 可容許的跨包的測試驅動程序依賴 266
2.14.6 盡量減少測試驅動程序對外部環境的依賴 268
2.14.7 堅持統一（獨立）的測試驅動程序調用接口 269
2.14.8 本節小結 270
2.15 從開發到部署 271
2.15.1 不應在軟件的靈活部署方面讓步 271
2.15.2 .h和.o文件名的唯一性非常關鍵 271
2.15.3 在開發過程中軟件組織會有所變化 271
2.15.4 在全公司范圍內讓名稱保持唯一有助于重構 272
2.15.5 在構建過程中軟件組織都可能有所變化 272
2.15.6 即使在正常情況下部署中仍需要靈活性 272
2.15.7 讓定制化部署成為可能是靈活性之價值的重要體現 273
2.15.8 頭文件中風格化呈現的靈活性 273
2.15.9 庫的部署方式不應架構顯著 273
2.15.10 出于工程原因對已部署的軟件進行劃分 274
2.15.11 出于業務原因對已部署的軟件進行劃分 275
2.15.12 本節小結 276
2.16 元數據 276
2.16.1 元數據即“法令” 277
2.16.2 元數據的類型 277
2.16.3 元數據的呈現 281
2.16.4 本節小結 282
2.17 小結 283
第3章 物理設計和分解 290
3.1 從物理的角度思考 290
3.1.1 純經典的（邏輯的）軟件設計是幼稚的 291
3.1.2 組件充當細粒度的模塊 291
3.1.3 軟件的設計空間是有方向性的 291
3.1.4 軟件有其絕對位置 292
3.1.5 并置與否的準則應該看本質，不應流于表面 293
3.1.6 不規整的非初等功能搜尋十分麻煩 293
3.1.7 包的作用域是一項重要的設計考量 293
3.1.8 禁止循環物理依賴帶來的一些限制 295
3.1.9 對友元的約束有意排除了某些邏輯設計 297
3.1.10 一個有正當理由要求包裝的 案例 297
3.1.11 本節小結 302
3.2 避免糟糕的物理模塊化 303
3.2.1 有很多糟糕的模塊化準則，語法是其中之一 303
3.2.2 將用途廣泛的軟件分解并加入庫中非常重要 303
3.2.3 迫于壓力未能維持應用/庫的模塊化 303
3.2.4 可復用組件的持續降級至關重要 304
3.2.5 對應用開發者而言，物理依賴不是實現細節 305
3.2.6 迭代器有助于減少初等功能的開發量 309
3.2.7 既要*小也要初等：實用結構體 309
3.2.8 總結性示例：封裝型多邊形類接口 309
3.2.9 語義與語法作為模塊化準則 322
3.2.10 本節小結 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 將緊密的相互協作并置于單個發布單元中 330
3.3.7 計算天數的示例 330
3.3.8 *后的示例：單線程引用計數型函子 336
3.3.9 本節小結 344
3.4 避免循環的連接時依賴 345
3.5 層級劃分技術 351
3.5.1 經典層級劃分技術 351
3.5.2 升級 352
3.5.3 降級 357
3.5.4 不透明指針 359
3.5.5 啞數據 365
3.5.6 冗余 367
3.5.7 回調 371
3.5.8 管理器類 389
3.5.9 分解 391
3.5.10 升級封裝 392
3.5.11 本節小結 407
3.6 避免過度的連接時依賴 408
3.6.1 起初分解妥當的日期類會隨時間退化 408
3.6.2 將工作日功能添加到日期類中（壞主意） 414
3.6.3 提供一個物理上整塊式的平臺適配器（壞主意） 415
3.6.4 本節小結 418
3.7 橫展架構與分層架構 418
3.7.1 另一個與建筑業的類比 419
3.7.2 （經典的）分層架構 419
3.7.3 對純組合式設計加以改進 421
3.7.4 *小化累積組件依賴度 421
3.7.5 基于繼承的橫展架構 424
3.7.6 橫展架構與分層架構的測試 427
3.7.7 本節小結 427
3.8 避免不當的連接時依賴 428
3.8.1 不當的物理依賴 428
3.8.2 在單一技術上“押注”（壞主意） 431
3.8.3 本節小結 436
3.9 確保物理互操作性 436
3.9.1 妨礙層次化的復用是壞主意 436
3.9.2 領域特定的條件編譯是壞主意 437
3.9.3 在庫組件中的應用特定的依賴是壞主意 439
3.9.4 約束并排型復用是壞主意 440
3.9.5 防止故意的濫用不是目的 441
3.9.6 讓組件侵占全局資源是壞主意 441
3.9.7 隱藏頭文件來實現邏輯封裝是壞主意 441
3.9.8 可復用庫中存在對不可移植軟件的依賴是壞主意 443
3.9.9 將潛在可復用軟件隱藏起來是壞主意 446
3.9.10 本節小結 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 本節小結 458
3.11 架構隔離技術 458
3.11.1 封裝與隔離的形式化定義 459
3.11.2 用組件的概念闡釋封裝與 隔離 459
3.11.3 整體隔離與部分隔離 460
3.11.4 架構顯著的整體隔離技術 461
3.11.5 純抽象接口（協議）類 461
3.11.6 完全隔離型具體包裝器 組件 467
3.11.7 過程接口 471
3.11.8 隔離和動態加載庫 484
3.11.9 面向服務的架構 484
3.11.10 本節小結 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 債券計息日數慣例 510
3.12.9 日期數學 510
3.12.10 日期和日歷實用件 513
3.12.11 充實分解透徹的實現 515
3.12.12 本節小結 527
3.13 小結 529
結論 536
參考文獻 538
展開全部
大規模C++軟件開發 卷1:過程與架構 作者簡介
約翰·拉科斯（John Lakos），《大規模C 程序設計》（Large-Scale C Software Design）一書的作者，任職于彭博有限合伙企業，擔任高級架構師，同時是全球C 軟件開發顧問。2001年他成立了彭博的BDE工作組，按照他的基于組件的方法論、過程和架構來開發細粒度的、可復用的C 軟件。他是ACCU、C Now、CppCon和Meeting C 等業內技術大會的常客，經常發表技術演講。他自2006年開始任C 標準委員會的投票成員，新一代C 的成型有他的一份功勞，包括C 11的值語義、C 17的PMR分配器和C 20的模塊。他于1996年出版的《大規模C 程序設計》一書是用C 做大型系統設計的開山之作，至今還是這個領域的常用參考書。
書友推薦
- >
羅庸西南聯大授課錄
- >
伯納黛特,你要去哪(2021新版)
- >
月亮虎
- >
我與地壇
- >
新文學天穹兩巨星--魯迅與胡適/紅燭學術叢書(紅燭學術叢書)
- >
詩經-先民的歌唱
- >
經典常談
- >
大紅狗在馬戲團-大紅狗克里弗-助人
本類暢銷
