Hiding your Implementation Details is Not So Simple
summary
Argues why simple rules like “make members private” fail in real C++ code and gives concrete recipes: when public pair members break lazy or generic code, prefer functions or value semantics; use wrapper class or interface to prevent callers from inserting or erasing map entries; Concepts document intent but do not prevent misuse; pimpl hides build details; use the private token idiom to let make_unique work with factory-only construction; prefer state/strategy and factories to hide hierarchies. Watch if you want practical fixes, code patterns and tradeoffs.
AI-written summary · about
chapters (15)
- 0:00Introduction and motivation
- 1:03Benefits of information hiding
- 2:53Challenges in information hiding
- 4:06Common implementation mistakes
- 8:31Analyzing std::pair and design
- 12:27Evolving interfaces and APIs
- 16:56API design principles
- 20:22SOLID and testing principles
- 22:48Context-specific design
- 25:52Strategies for better encapsulation
- 30:45C++20 Concepts and hiding details
- 36:46Practical exercises in encapsulation
- 53:12Managing hierarchies and pointers
- 58:20Advanced patterns for API enforcement
- 1:11:10Conclusion and Q&A
related talks
01h 03mHiding Your Implementation Details in C++ is Not So Simple
59mBuilding Cpp Interfaces That Are Hard to Use Incorrectly
05mOn using singletons in C++
43mDesign Patterns - The Most Common Misconceptions (1 of N)
54mWriting C++ to Be Read
01h 07mDesign Patterns in Modern C++
01h 22mSimplicity: not just for beginners
01h 02mRetiring the Singleton Pattern: Concrete Suggestions for What to use Instead