Developing Better C++ Code by Isolating Decisions
summary
Claims that Decision-Making Isolation—pulling branching and algorithms into pure free functions or tiny classes, injecting IO and wiring separately—makes C++ code more readable, extensible, and testable. Implementation follows C++ Core Guidelines, uses dependency injection (including supplying a clock function instead of calling steady_clock), and exercises GTest for decision logic; the team at Plexus is trialing it on components (not yet a full project rollout). Outcome: fewer, higher-value tests, less coupling and brittle mocks after several redesign cycles (four to six iterations).
AI-written summary · about
chapters (30)
- 0:00Introduction and vision
- 2:06Personal journey
- 4:14Testing as a solution
- 6:28Rethinking unit testing
- 8:33Defining quality code
- 10:58Software design principles
- 13:28The challenge of SOLID
- 18:20Arbitrary points in design
- 21:08Decision-making isolation
- 24:05Example refactoring
- 25:50Types of DMI code
- 28:33Isolating decisions
- 32:27Identifying decision logic
- 35:33Understanding IO code
- 37:55Wiring components together
- 39:29Classes vs structs
- 42:28Defining invariants
- 46:12RAII and resource management
- 48:03Property invariants
- 49:56Class invariant example
- 52:04Handling data without invariants
- 55:04Value of free functions
- 59:30Component boundaries
- 1:03:09DMI and SOLID principles
- 1:05:54Unit testing strategy
- 1:08:23Refactored testing example
- 1:11:23Testing wiring and IO
- 1:14:15Test-driven development
- 1:16:43Conclusion and takeaways
- 1:19:22Q&A and closing remarks
related talks
45mC++: How Software Engineering Will Destroy Your Project?
44mReversible Decisions for Better Software Design
45mPostmodern Programming
01h 28mLaw of Demeter: A Practical Guide to Loose Coupling
01h 30mC++ Modules and Large-Scale Development
01h 01mEasy to Use, Hard to Misuse: Declarative Style in C++
51m“Postmodern C++”
54mWriting C++ to Be Read