4 ms·
In my experience, implementation inheritance always makes the problems you complain about worse, not better. With implementation inheritance you've got to go a
by bunderbunder 12y ago
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 12y ago> 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 12y agoExactly. It’s what I commented about super after 8. You spread your (probably stateful, imperative) logic over several files and classes.
- zzzcpan 12y ago> 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.