3 ms·
Something one often sees in Go (which is in my mind an anti-pattern) is the supplier of an object also supplying an equivalent interface, as they would in Java
by jen20 2y ago
Something one often sees in Go (which is in my mind an anti-pattern) is the supplier of an object also supplying an equivalent interface, as they would in Java or another nominative adoption system. In Go, the interface belongs to the consumer!
- slekker 2y agoBut how do you avoid duplicating the interface in many places? We've tried both approaches, declaring the interface in one package and importing it where used but also declaring it directly colocated with the consumer. I've found the first approach worked better when we had to add or modify the interface methods
- jen20 2y agoYou don’t. Each consumer of something declares what it needs via an interface, something concrete may be passed that implements it - including fakes for tests. Of course this doesn’t apply when using interfaces for polymorphic return types in a library, but that is a distinct use case for interfaces to address. Perhaps some of this is just taste, but this is the way I’ve found interfaces in Go to be most useful.