John Lakos, manager at Bloomberg, runs their BDE group, which develops fine-grained reusable C++ software using his component-based methodology and process. He also mentors engineers and team leads throughout Bloomberg’s software infrastructure department. As a voting member of the C++ Standards Committee, he has helped shape new generations of C++. He is the author of Large-Scale C++ Software Design (Addison-Wesley, 1996).

Preface xvii
Acknowledgments xxv
Chapter 0: Motivation 1
0.1 The Goal: Faster, Better, Cheaper! 3
0.2 Application vs. Library Software 5
0.3 Collaborative vs. Reusable Software 14
0.4 Hierarchically Reusable Software 20
0.5 Malleable vs. Stable Software 29
0.6 The Key Role of Physical Design 44
0.7 Physically Uniform Software: The Component 46
0.8 Quantifying Hierarchical Reuse: An Analogy 57
0.9 Software Capital 86
0.10 Growing the Investment 98
0.11 The Need for Vigilance 110
0.12 Summary 114
Chapter 1: Compilers, Linkers, and Components 123
1.1 Knowledge Is Power: The Devil Is in the Details 125
1.2 Compiling and Linking C++ 129
1.3 Declarations, Definitions, and Linkage 153
1.4 Header Files 190
1.5 Include Directives and Include Guards 201
1.6 From .h /.cpp Pairs to Components 209
1.7 Notation and Terminology 216
1.8 The Depends-On Relation 237
1.9 Implied Dependency 243
1.10 Level Numbers 251
1.11 Extracting Actual Dependencies 256
1.12 Summary 259
Chapter 2: Packaging and Design Rules 269
2.1 The Big Picture 270
2.2 Physical Aggregation 275
2.3 Logical/Physical Coherence 294
2.4 Logical and Physical Name Cohesion 297
2.5 Component Source-Code Organization 333
2.6 Component Design Rules 342
2.7 Component-Private Classes and Subordinate Components 370
2.8 The Package 384
2.9 The Package Group 402
2.10 Naming Packages and Package Groups 422
2.11 Subpackages 427
2.12 Legacy, Open-Source, and Third-Party Software 431
2.13 Applications 433
2.14 The Hierarchical Testability Requirement 437
2.15 From Development to Deployment 459
2.16 Metadata 469
2.17 Summary 481
Chapter 3: Physical Design and Factoring 495
3.1 Thinking Physically 497
3.2 Avoiding Poor Physical Modularity 517
3.3 Grouping Things Physically That Belong Together Logically 555
3.4 Avoiding Cyclic Link-Time Dependencies 592
3.5 Levelization Techniques 602
3.6 Avoiding Excessive Link-Time Dependencies 704
3.7 Lateral vs. Layered Architectures 722
3.8 Avoiding Inappropriate Link-Time Dependencies 739
3.9 Ensuring Physical Interoperability 753
3.10 Avoiding Unnecessary Compile-Time Dependencies 773
3.11 Architectural Insulation Techniques 790
3.12 Designing with Components 835
3.13 Summary 908
Conclusion 923
Appendix: Quick Reference 925
Bibliography 933
Index 941