# No Interface Is A Good Interface
First of all, don't start out with an
interface right at the very beginning. Only create one if you later on come to the conclusion that you really have to, because chances for truly needing one are actually slim.I experience that at my dayjob, too. There is a code base where I always wonder why certain interfaces exist in the first place. They're all implemented by exactly one type each, which is kind of useless. Just the type alone would totally suffice.
That train of thought to always also have an interface along with an implementing type might come from the Java enterprise world, at least that's where I encountered it really heavily. I never liked that. It just makes the code arbitrarily more complicated than it needs to be. The best code is the one that doesn't even exist. Simpler is better. Complexity is the root of all evil.
Advocates of the type with interface faction then like to argue: "But maybe sometime in the future we would like to create a second type that implements this interface, you will never know@11!! Or think of refactoring, we can also change the underlying implementation completely when we have an interface in front of it without people knowing!" But that basically never happens in reality. It reminds me a bit of premature optimization, preparing for the unknown future. Firstly, things turn out differently and secondly, other than one thinks. :-)
To be fair, thinking about what might happen or not is still a very valid thing. In my opinion it is even done not enough in this agile world. Implementation first, consideration second (if at all). But there are limits. So, start out simple. No interface for you at first.
That general rule goes at least for application development, it can be a little bit different when you write a library. More flexibility _might_ be actually helpful there.
# Interface Placement
When you define an actually beneficial
interface, then place it in the same package where it is actually used in. Or lexically close to where is is used for that matter. As oposed to in the package where the implementing type resides in. This recommendation is very logical to me. The interface describes the API, so it should also go along with the rest of our API.# Return Values
When you have a factory function to create a type that implements an interface, return that implementing type, not the interface. Using ugly suffixes in identifiers to help visualize the concept:
o
type FooInterface interface {
Foo()
}
type FooImplementation struct { }
func (f *FooImplementation) Foo() { }
func NewFoo() *FooImplementation /* as opposed to FooInterface */ {
return &FooImplementation{}
}
Most of the time I agree on that rule (it feels natural and correct), sometimes I don't. I reckon this depends on the exact use case at hand.
# Testing
When you have a type that you want to test, the recommendation is to not create dedicated interfaces for testing purposes only in order to mock something. If you do, this smells like a bad API design of the type in the first place. Instead, try to make its regular, productive API better, so it can be also used when testing the type.
Phew, this turned out to be a much longer post than I first anticipated. ;-) I hope this helps a bit.