Where Are You Putting Your Interfaces?

Are you putting interfaces in the best places? This simple decision can change your Go codebase’s maintainability and clarity.

“Near, far, wherever you are’”— Celine Dion sang about eternal love in her famous Titanic Theme. But these words strike a different chord for us Software Engineers. Today, we’re not navigating icy waters but the world of interfaces. And trust me, in this article, “near” and “far” have a different meaning than “just” a lyric in a love song!

So, let’s talk about distance — not in terms of romance, but in the context of our codebase. Distance matters.

I realized it today. I was trying to define some guidelines for my company with my colleagues, and the question of where to place interfaces in our codebase came up.

A library had a problem with a complex object that had several methods. The issue was that the interface for this object was also exposed, which caused problems. A small detail: the implementation had a new method, but the interface did not. We had to include a new method in the interface so that a new object in our codebase could use it.

This led to the question: do all the objects that depend on that interface need this method? The answer is no.