SOLID Go Design
summary
Argues that SOLID maps to Go mainly through interfaces and packages, with concrete examples: replacing a function signature from os.File to io.ReadWriteCloser then finally io.Writer to narrow responsibilities and ease testing, and using embedding preserves method sets so types are open for extension but closed for modification; shows reader/io patterns as real substitution examples; warns of future scale with 500,000 Go developers by decade end and urges prioritizing decoupled design over frameworks and micro-optimizations.
AI-written summary · about
chapters (15)
- 0:00Intro
- 0:51Who does code review as part of their job?
- 3:16Good Design
- 4:02Single Responsibility Principle
- 4:59Coupling & Cohesion
- 7:24Go's UNIX philosophy
- 10:25Liskov Substitution Principle
- 10:52Interfaces!
- 11:30Simple Implementations
- 12:52Interface Segregation Principle
- 18:58Dependency Inversion Principle
- 19:10High-level modules should not depend on low-level modules. Both should depend on abstractions.
- 21:08SOLID Go Design
- 22:02Interface Substitution Principle
- 22:40Interfaces let you apply the SOLID principles to Go programs
related talks
01h 00mSOLID Revisited : The State of the Matter
01h 19mSOLID Revisited: The State of the Matter
34mWriting idiomatic Go using Domain Driven Design
41mIs Your Code Too SOLID?
46mWhy you can't use GO! (away from anti-patterns)
44mHow Do You Structure Your Go Apps?
44mHow Do You Structure Your Go Apps?
37mHonest mistakes caused by shallow interpretation of SOLID