·熱銷圖書作者約翰·拉科斯（John Lakos）新作，將其在C++領域超過30年的經驗彙聚於此，幫助讀者學到實用的知識和技能。·大規模C++編程全解，內容豐富。從設計理念到開發過程，從方法論到技術工具，無一不包，讓讀者深入了解大規模C++軟件開發的各個方面。·不僅介紹理論知識，還通過具體示例展示了開發實踐。在實際開發應用中，提高開發效率和代碼質量。 ·繫統介紹設計概念，為大規模的項目奠定基礎。無論你是C++初學者還是經驗豐富的開發者，都會受益匪淺。

●第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“HelloWorld!”70
1．1．2創建C++程序71
1．1．3頭文件的作用72
1．2C++程序的編譯和連接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．16extern模板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組件特性1123
1．6．2組件特性2125
1．6．3組件特性3126
1．7符號和術語128
1．7．1概要128
1．7．2Is-A邏輯關繫130
1．7．3Uses-In-The-Interface邏輯關繫130
1．7．4Uses-In-The-Implementation邏輯關繫131
1．7．5Uses-In-Name-Only邏輯關繫和協議類133
1．7．6In-Structure-Only（ISO）協作式邏輯關繫135
1．7．7受約束模板和接口繼承的相似之處136
1．7．8受約束模板和接口繼承的不同之處137
1．7．93種“繼承型”關繫各有所長138
1．7．10給模板的類型約束編寫注釋139
1．7．11本節小結140
1．8Depends-On關繫141
1．9隱含依賴144
1．10層級編號149
1．11抽取實際的依賴151
組件特性4152
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．12using指令和聲明往往是壞主意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數據276
2．1數據即“法令”277
2．1數據的類型277
2．1數據的呈現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．的約束有意排除了某些邏輯設計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．3C++中的編譯時耦合比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++開發的基本設計設想，為各種規模的項目奠定基礎，並演示成功進行大規模實際開發所需的過程、方法、技術和工具。通過閱讀本書，讀者可以逐步改變自己的設計和開發方法。本書旨在使用軟件從業人員熟悉的C++構件來解決現實問題，同時確定（並激發）現代C++替代方案。作者利用超過30年的構建大規模、關鍵任務的企業繫統的實踐經驗，展示了如何創建和增長軟件資本。
本書專為有經驗的C++軟件開發者和繫統設計師編寫，從事大型軟件開發工作的架構師或項目負責人等也可以通過閱讀本書解決實際工作中的問題。

(美)約翰·拉科斯 著 魏文崟 譯