November 7, 2025
Small interfaces, big feelings
Revisiting Interface Segregation in Go
Go devs feud over tiny interfaces: clean code or chaos
TLDR: A Go post pushes using small, single-purpose interfaces to simplify testing and design. Comments split between fans of micro-interfaces, critics warning it turns into duck-typing chaos, and .NET folks saying mocks already solve this—making it a battle over simplicity vs future flexibility.
A Go blog revisits the Interface Segregation Principle (ISP)—the idea that code should only depend on what it actually uses—and the crowd came ready to spar. The post shows how slicing a big “Storage” into a one-method “Saver” makes testing easier and lets you swap implementations without drama. The community? Absolutely not chill. One engineer bragged they’ve taken interface segregation to the extreme, carving out bite-size interfaces per package with matching mocks. Another pointed to the classic mantra “The bigger the interface, the weaker the abstraction” like it was a gospel verse.
Then the backlash: a commenter warned this path leads straight to Python-style “duck typing” and all the foot-guns that come with it. Cue retorts: “Why add methods to public interfaces anyway?” and “What if Backup needs Load later—do we keep shrinking and growing forever?” Cross-ecosystem shade flew in from .NET land, where mocking tools let you stub just the methods you need, no micro-interfaces required. Memes landed fast: “Go on a one-method diet,” “S3Client doing cardio,” and “micro-interfaces, macro feelings.” The vibe is classic dev drama—minimalist zeal vs future-proofing anxiety—wrapped in a surprisingly relatable question: how small is too small?
Key Points
- •The article applies the Interface Segregation Principle (ISP) to Go, advocating that functions should not depend on methods they do not use.
- •An initial design couples a function (Backup) to a concrete type (FileStorage), limiting flexibility and complicating testing due to side effects.
- •Refactoring to an interface (Storage) decouples behavior from implementation, enabling alternate backends and easier test doubles.
- •Further narrowing to a minimal interface (Saver) that only includes Save aligns dependencies with actual usage and simplifies mocks/fakes.
- •Go’s implicit interface satisfaction enables types to automatically satisfy minimal interfaces, improving clarity, testability, and maintainability.