Policies for coding

[Gustavo Niemeyer]

On Mon, Aug 26, 2013 at 12:12 PM, William Reade
<william.reade at canonical.com> wrote:
> It's enough of a hassle updating the client code that you control when you
> have to make a change like this; and if anyone *else* depends on that
> package, game over. Frequently you just sigh, and use the concrete types,
> and move on. And the client test suite just has to suck it up and become
> that little bit less wieldy.

I'm skeptical of any coding practice that turns the use of concrete
types into a religious matter. There are all sorts of situations, and
what we want is to avoid the pitfalls. There are many different routes
to do that. Often all that is necessary is a parameter to specify a
test file location, or change a delay, or a flag to turn something
off.

There are cases test doubles (mocks, fakes, whatever) are helpful, of
course, but they're just one more tool.

> And that's why we should generally prefer to return interfaces -- because
> the cost of doing so and not needing to is negligible, but the cost of doing
> after the fact approaches the prohibitive with alarming stealth and speed.

Why?  What's the big deal about replacing a type with an interface,
and how often does it actually happen?

> This is not to say that you *can't* return structs... but you almost
> certainly shouldn't return structs with private fields, or structs whose
> public fields could take a lot of work to set up, or structs that might
> legitimately come to fall under those categories.

That's quite surprising, and unlike anything else I've been doing or
watching around Go.

> Tim may have found other problems, but that's the general shape of the ones
> I've found. Interfaces are great, but you have to *use* them, and it's not
> trivial to bolt them on.

Yes, use them when you can clearly explain why for the case at hand.
Bolting them on by default just because you might need it to be an
interface eventually seems like a bad practice.


gustavo @ http://niemeyer.net