OOPs!... I Did it Again: When Good Objects Go Toxic
summary
Shows Java-based library examples that break a bloated Title/Item parent into domain models, moves catalog/copyright/metadata responsibilities into separate classes, and converts deep "is-a" hierarchies into has-a relationships. Demonstrates removing abstract methods from the top-level class, implementing domain-specific search/download/renew behavior, and treating the pattern as a shared identity model to avoid fragile coupling. Emphasizes concrete steps: map workflow, split responsibilities, refactor to composition, and remove abstract from parent to reduce costly refactors.
AI-written summary · about
chapters (10)
- 0:00Toxic OOP design intro
- 1:14What is a toxic object
- 2:59Pitfalls of object-oriented programming
- 4:46OOP pillars misuse
- 5:07Identifying and fixing God objects
- 13:34Three steps to eliminate God objects
- 14:57Dangers of over-inheritance
- 16:44Scalable inheritance
- 22:00Composition over inheritance
- 23:42Key takeaways
related talks
21mData-Oriented programming
48mOOP revisited
45mOOP revisited
38mWhat Object-Oriented Programming Was Supposed to Be: Two Grumpy Old Guys’ Take on ...
43mGo Ahead, Make a Mess
52mBreaking Bad Code: From simple problems to complicated solutions and back
01h 05mFrom object oriented to functional domain modeling
35mThe League of Extraordinary Antipattern