Deconstructing Inheritance
summary
Argues that inheritance as commonly used in C++ fails specific tests: the rectangle vs square example shows broken interfaces and wasted storage, elevator/button and flying/duck examples expose hidden client coupling, and the Liskov substitution principle is shown impractical in a strict or relaxed sense. Proposes concrete alternatives — composition, narrow interfaces, and type erasure — and demonstrates when inheritance actually increases complexity versus when composition over inheritance or pure interfaces produce simpler, safer designs.
AI-written summary · about
chapters (23)
- 0:00Intro
- 1:22deconstruction
- 1:43inheritance in C++
- 3:25problem statement
- 3:42two solutions
- 9:39problem: elevator system
- 11:07what is real-world?
- 11:38what is a Button?
- 14:17IS-A in software
- 16:07public inheritance is substitutability
- 17:43Liskov Substitution Principle
- 19:41LSP, strict sense
- 24:05LSP can break
- 27:36NOT an abstraction
- 28:40real-life analogy
- 29:14friendship impact
- 30:12inheritance impact
- 31:08example
- 33:28change inertia
- 36:43prefer composition to inheritance
- 38:23why use inheritance?
- 43:01interface guidelines
- 51:09source of problems
related talks
01h 02mBreaking Dependencies: Type Erasure - A Design Analysis
05mLightning Talk: Is Polymorphism in C++ Really That Bad?
01h 01mBreaking Dependencies - C++ Type Erasure - The Implementation Details
01h 03mType Erasure - The Implementation Details
57mOo Considered Harmful
44mPragmatic Type Erasure: Solving OOP Problems w/ Elegant Design Pattern
03mLightning Talk: Interfaces in C++
01h 05mExpressing Implementation Sameness and Similarity - Polymorphism in Modern C++