5-interface-pollution/

[giscus[bot]]

5-interface-pollution/

None

https://100go.co/5-interface-pollution/

[myrachanto]

This was quite helpful, thank you

[1buran]

Nice explanation, thanks 👍

[wade30822]

Excellent👍

[KDL-in]

Thank you for your book. I bought the physical version, but I still feel that the e-book version is more convenient (for computer technology books), especially when it comes to the source code part. I hope that the entire book has a complete electronic version.

[teivah]

Yes, there are electronic versions of the book available. Please check https://100go.co/book.

[zakaria-chahboun]

Cool!

[mumy81]

Thanks for the explanation—it's really helpful. However, I'd love to see some concrete examples of what you consider “interface pollution” in Go. For instance, unit testing often drives us to rely on interfaces everywhere—especially for passing dependencies. Is that approach itself considered interface pollution?

Devs that have C# and Java backgrounds commonly use large, compound interfaces, which you've pointed out is typically an anti-pattern in Go. But at the same time, small, concise interfaces are critical for making Go code testable and mockable. How do we strike a balance between using many small interfaces for testability without polluting the codebase with too many interfaces?

[ericgreene]

Personal opinion, but using interfaces for unit testing is interface pollution. There are times that it is valid to use, but often there is a lower-level interface that can work so that tests run through all of your own real code rather than a stub or mock.
For instance, methods that make http clients, you can alter the round tripper in the test to set the desired response, ensuring that all of your code is actually executed.
Another approach I would take before using interfaces to allow for testing is to refactor the method so that as much non-networked logic as possible has been extracted into simple functions (input/output, no networking). And those can be easily unit-tested.

There is a cost for every added abstraction that results in slower development time, and non-effective testing methods.