3 ms·

> Interfaces in golang ... provide a better solution to that Hm. What exactly are we talking about here? What problems inheritance and interfaces attempt to so

by zzzcpan 12y ago

> Interfaces in golang ... provide a better solution to that Hm. What exactly are we talking about here? What problems inheritance and interfaces attempt to solve? I mostly see abuse and overuse of interfaces in golang. It takes way too much time to understand what's going once you have an interface somewhere. The code starts to feel awfully OOish. You start guessing and assuming things, because you get that virtual thingy and finding what's behind this thingy and where is too much effort, you also have to get out of context. OO programmers have IDEs to help with that, but golang is anti-IDE. As a bonus you get that evil OOish style of manipulating internal state from a whole bunch of different methods that call other methods that change state. I guess they like to follow DRY dogma or whatever. Anyway, I don't see how interfaces are better than OO.

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 ago
  Exactly. 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.

by zzzcpan 12y ago

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 ago
Exactly. 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.