[bunderbunder]

In my experience, implementation inheritance always makes the problems you complain about worse, not better. With implementation inheritance you've got to go and trace a class's entire inheritance hierarchy all the way back to the root if you want to reason about a method's behavior. With interface inheritance the number of implementations you need to look at is always 1.

More generally, interfaces give you a way to provide an absolute minimum in semantic guarantees down toward the root of your inheritance hierarchy. This is critical if you want to follow the Liskov substitution principle. And you should always want to follow LSP.

[zzzcpan]

> With interface inheritance the number of implementations you need to look at is always 1.

Well, I haven't seen real need for neither of them. Both seem to only make things worse, not better.

[Profpatsch]

Exactly. It’s what I commented about super after 8.

You spread your (probably stateful, imperative) logic over several files and classes.

[zzzcpan]

> You spread your (probably stateful, imperative) logic over several files and classes.

It's just as awful in Go code that uses interfaces. State changes are still scattered all over the place. You still have to keep a model of everything in your mind to understand what some method does and what states it changes and what effects those changes have on other methods and so on. My point is: interfaces don't offer noticeable improvements over inheritance.

Building abstractions around state changes instead would be much better way, especially considering that Go supports function literals and closures. But nobody does that :( People prefer to abuse interfaces.