Clean Up Your GOOOP: How to Break OOP Muscle Memory
summary
Claims that copying class-based OOP into Go creates brittle “goop” backed by concrete examples: embedding vs inheritance breaks polymorphism (embedded field calls base method, not overridden one), a shared refactor into a new clients module forces extra versioning and coordination across services, an S3-style API with 91-method interface proves unwieldy, and a real package reorganization cuts downstream build times from ~7–8 minutes to under a second and binary size from ~80 MB to ~7–8 MB. Consumer-defined small interfaces and package-per-functionality replace heavyweight OO patterns.
AI-written summary · about
chapters (11)
- 0:00Introduction to Dylan
- 1:03What is Goop?
- 2:00Academic roots of OOP
- 4:41Go structs vs classes
- 5:49Embedding vs inheritance
- 9:05Packages as design units
- 11:17Refactoring pitfalls
- 15:23Consumer-defined interfaces
- 21:01Idiomatic project structure
- 27:47Applying SOLID in Go
- 32:06Conclusion
related talks
33mIs Go Object-Oriented? A Case of Public Opinion
04mGo is a great OO language
48mClear Is Better Than Clever - What Makes Go Stand Out
23mRefactoring Go in Large Codebases
23mSimplicity is Complicated
44mHow Do You Structure Your Go Apps?
17mFrom Java to Go: I Have a Hammer and See Nails Everywhere
05mComposition Over Inheritance