Hiding Your Implementation Details in C++ is Not So Simple
summary
Argues that putting fields private is necessary but not sufficient and shows concrete fixes: replacing public std::pair-style members with getters to allow lazy or changed representation, wrapping associative containers into a mutable-values wrapper so callers can change values but not keys, avoiding protected data in favor of protected functions, preferring interfaces or narrow return concepts over returning std::vector, and using a private-token/passkey idiom to keep constructors public for make_unique while preventing external construction.
AI-written summary · about
chapters (24)
- 0:00Introduction
- 2:36Hiding details complexity
- 4:01Public members problems
- 7:10Abstraction vs performance
- 10:45Context-specific exposure
- 13:20Private IDs initially
- 15:27Master and dog story
- 17:33Lean and decoupled APIs
- 21:26Exercise: modify map values
- 25:52Solution: wrapper for hiding
- 27:18Hide hierarchy and pointers
- 31:57State pattern for transitions
- 35:27Strategy pattern for algorithms
- 36:53Factory methods for types
- 37:15Less info in returns
- 40:49Interfaces or concepts
- 43:38Proxies pitfalls
- 45:24Enforce call order
- 47:54Protected members rarely justified
- 50:44Test private behavior
- 52:27Hide types in namespaces
- 53:09Private token idiom
- 55:16Summary
- 56:24Q&A
related talks
01h 20mHiding your Implementation Details is Not So Simple
54mWriting C++ to Be Read
01h 07mDesign Patterns in Modern C++
59mBuilding Cpp Interfaces That Are Hard to Use Incorrectly
01h 22mSimplicity: not just for beginners
01h 01mEasy to Use, Hard to Misuse: Declarative Style in C++
36mInterfaces Matter
01h 02mFree Your Functions!