3 ms·

Interesting. I'm moving away from interfaces and toward plain structs (not consciously, but naturally). I tend to only use interfaces when I want polymorphism,

by weberc2 10y ago

Interesting. I'm moving away from interfaces and toward plain structs (not consciously, but naturally). I tend to only use interfaces when I want polymorphism, not modularity. This is probably a consequence of me moving away from a mock-all-the-things approach to testing.

skybrian 10y ago
I recently heard a rule of thumb: "accept interfaces, return structs". I haven't put it into practice, but it seems like this should give callers enough flexibility to pass in whatever they like.
- zalmoxes 10y ago
  That really depends on what you're tying to do. Say you have a Datastore interface, which has some methods like "Create", "Update", "Delete", and a MySQL + an inmem implementation. You can have `datastore.New() Datastore`, which returns one of the implementations, or you can have `datastore.NewMySQLStore, datastore.NewInMemStore()`. Now you need a different method for each implementation. Also be careful with returning concrete type, you can run into this issue: https://play.golang.org/p/WHAW1X6elS https://play.golang.org/p/WHAW1X6elS
  - patates 10y ago
    Wow, that seems like a big issue. Is this accepted as a bug and being worked on or yet another feature?
    - weberc2 10y ago
      It's not a bug. Interfaces are reference types. In this case, the interface is implemented by a pointer type. The interface can be thought of as a pointer to a nil pointer, but the "interface pointer" itself is not nil. This is a tricky concept until you learn that interfaces are reference types. Here's a simplified version of the previous example that illustrates this concept: https://play.golang.org/p/pODBgaHXq5 https://play.golang.org/p/pODBgaHXq5
- lloeki 10y ago
  Indeed I remember someone laying out some Go good practices (Rob Pike? Andrew Gerrand? damn can't recall) and "accept interfaces, return types" was definitely one of them. Again, a rule of thumb that works very well in most (not all) cases, and, conversely, a code smell.
- weberc2 10y ago
  Hmm, I'm not sure that rule of thumb is very good. I think a better one would be "accept interfaces when you want polymorphism". Often I have a very high degree of confidence that your caller will never want to pass a different implementation, and creating the extra interface for an improbably hypothetical situation just isn't worth my time? I'm not making any statements here, just wondering out loud.
solipsism 10y ago
Toward what kind of testing, mind sharing?
- weberc2 10y ago
  I'm not sure that there is a name for it, but I construct my unit with its real dependencies (except for I/O or IPC). I've found that mocking ends up tightly coupling your tests to the implementation (not the behavior) of your unit. This means changes to your unit's implementation (that don't change its behavior) create a bunch of test failures. Also, mocking in Go isn't as easy as in Python, so even installing the mocks is a bit of work.

by weberc2 10y ago

skybrian 10y ago

I recently heard a rule of thumb: "accept interfaces, return structs". I haven't put it into practice, but it seems like this should give callers enough flexibility to pass in whatever they like.

zalmoxes 10y ago
That really depends on what you're tying to do. Say you have a Datastore interface, which has some methods like "Create", "Update", "Delete", and a MySQL + an inmem implementation. You can have `datastore.New() Datastore`, which returns one of the implementations, or you can have `datastore.NewMySQLStore, datastore.NewInMemStore()`. Now you need a different method for each implementation. Also be careful with returning concrete type, you can run into this issue: https://play.golang.org/p/WHAW1X6elS https://play.golang.org/p/WHAW1X6elS
- patates 10y ago
  Wow, that seems like a big issue. Is this accepted as a bug and being worked on or yet another feature?
  - weberc2 10y ago
    It's not a bug. Interfaces are reference types. In this case, the interface is implemented by a pointer type. The interface can be thought of as a pointer to a nil pointer, but the "interface pointer" itself is not nil. This is a tricky concept until you learn that interfaces are reference types. Here's a simplified version of the previous example that illustrates this concept: https://play.golang.org/p/pODBgaHXq5 https://play.golang.org/p/pODBgaHXq5
lloeki 10y ago
Indeed I remember someone laying out some Go good practices (Rob Pike? Andrew Gerrand? damn can't recall) and "accept interfaces, return types" was definitely one of them. Again, a rule of thumb that works very well in most (not all) cases, and, conversely, a code smell.
weberc2 10y ago
Hmm, I'm not sure that rule of thumb is very good. I think a better one would be "accept interfaces when you want polymorphism". Often I have a very high degree of confidence that your caller will never want to pass a different implementation, and creating the extra interface for an improbably hypothetical situation just isn't worth my time? I'm not making any statements here, just wondering out loud.

solipsism 10y ago

Toward what kind of testing, mind sharing?

weberc2 10y ago
I'm not sure that there is a name for it, but I construct my unit with its real dependencies (except for I/O or IPC). I've found that mocking ends up tightly coupling your tests to the implementation (not the behavior) of your unit. This means changes to your unit's implementation (that don't change its behavior) create a bunch of test failures. Also, mocking in Go isn't as easy as in Python, so even installing the mocks is a bit of work.