3 ms·

"The bigger the interface, the weaker the abstraction." - https://www.youtube.com/watch?v=PAAkCSZUG1c&t=5m17s https://www.youtube.com/watch?v=PAAkCSZUG1c&t=5m17

• feoren 4y ago
  That's basically right, but not really for the right reasons. What exactly does "smaller" mean? Rob Pike is saying they have few methods. We're kinda getting to the right ideas without understanding why. It still sounds like you (and Rob Pike, from the bit I listened to) are still thinking of abstractions as a feature list, and you're saying: instead of having one list of lots of features, have lots of lists of one feature. Okay, but ... we're still missing the point. It's not about features. It's about needs. How do you know whether an abstraction can be "smaller"? What does "smaller" mean? Smaller means: more generic and/or easier to implement. That is not the same as having fewer methods, even if that is often the result. An abstraction can be smaller if you can make it more generic, and/or easier to implement, and have it still do everything you need it to do.
  • Xeoncross 4y ago
    An interface must be a small as possible to fulfill it's purpose, no smaller and no larger. It's not about implementation, it's about the mental model of what is expected and why. Another way to say this is that an interface must be perfectly sized, but perhaps that is to abstract to be useful. Rob Pike mentioned few methods because that is the only thing that interfaces mean in Go - he might have used different terminology in another context or speaking about abstraction of systems instead of interfaces alone as abstractions.