Minimal Interfaces Drive Testability and Decoupling

Go's implicit interface satisfaction creates a fundamentally different design philosophy than most languages. Rather than declaring that a type implements an interface, Go allows any type to satisfy an interface by implementing its methods. This means you can define small, focused interfaces (1-3 methods) without worrying about breaking existing code or creating complex inheritance hierarchies. When interfaces are this lean, they become composable building blocks. A logger that accepts a simple Write method interface can work with files, network sockets, or test mocks without modification. This approach eliminates the fragile base class problem and makes testing dramatically easier since mock implementations require minimal code.

Interface Design Patterns in Go

The table above shows common patterns. Notice that even dual-method interfaces remain highly focused. When you're tempted to create interfaces with more methods, that's often a signal to decompose into smaller contracts. Always return concrete structs with methods, not interfaces, to provide rich behavior while keeping interfaces minimal.

Implicit Satisfaction Enables Clean Architecture

Go's lack of explicit interface inheritance means you can organize packages independently without import dependencies. A package defining a Logger interface doesn't need to import packages that implement it. This inverts the dependency graph compared to languages with explicit interface implementation. Your database package doesn't need to know about your logging package. Your logging package doesn't need to know about specific implementations. Everything just needs to satisfy the interface contract. This decoupling is what makes Go codebases remain modular even as they scale. You can refactor implementations or swap providers without cascading changes through your codebase.

When to Avoid Empty Interfaces and Type Assertions

The empty interface interface{} (now any in Go 1.18+) defeats type safety and should be reserved for truly generic operations like encoding or reflection. Type switches and type assertions introduce runtime overhead and reduce compile-time guarantees. Instead of using empty interfaces liberally, define small concrete interfaces for your use case. If you find yourself reaching for interface{} frequently, you're likely avoiding proper abstraction. Type assertions are useful when you genuinely need runtime polymorphism with heterogeneous types, but this should be rare in well-designed Go systems. Strongly typed code catches errors early and makes your intent explicit for other developers.