On Go Libraries Authors Coding to Interfaces
One convention of the Java programming world that I really like is the encouragement of writing code to interfaces instead of concrete types. When deciding on a type for a new variable or field, you’re advised against choosing concrete types like
HashMap, unless you have a specific need for them. Instead, you’re encouraged to use interface types, like
Map, so if it’s necessary to change the specific implementation, you can do so without changing the type of that field or variable. This is especially useful when dealing with libraries, where you may not have full control over the source code.
It would be nice if this convention showed up a bit more often in Go, particularly in libraries. There have been two instances in the last week when I wished the developer of a third-party library used an interface instead of a concrete type. My needs deviated a bit from the concrete type they were using, and if the library author used an interface instead, I could have coded up a type that wrapped the concrete type with some custom logic that satisfied my use case.
Instead, I either need to look for another library, or consider submitting a pull request which changes that concrete type to an interface.