My vote would be "it depends" :) You mentioned several different instances of tradeoffs:
* I find io.Writer a bit special, because of it's pervasiveness; let's talk about image.Image, which is probably closer to what you're asking. It makes sense for the image package to bundle the Image interface with various implementations of it, the implementations likely share a bunch of code and you want the interface to be clear and centrally available, so that other packages can put it in their signatures and things work. Note, though, that even though the types also implement the draw.Image interface, that's in a different package. * Encoding makes sense in it's own package; the encoders won't share a lot of code so it makes sense to put them into separate packages (also encouraging smaller binaries; don't need to link in encoders that won't be used). At the same time, you want the interfaces to, again, be centrally defined, so that other packages can use them in their own type definitions (which, AFAIR, is how that package came to be in the first place <https://docs.google.com/document/d/1u1a0ZxxBHWx5OCNNHXXR-yXl5ry5RM7DLlYy-5bjBE8/pub>). Thus, it makes sense to put the interfaces in a separate package at the place where it is in the hierarchy. * database/sql doesn't have a real need for defining the interface. While it's definitely sensible to have an interface abstracting over a database for testing purposes or some abstractions in limited cases, in general, people will just use the concrete struct implementation and that's fine. Thus, in that case it makes sense to not have an interface at all and leave that up to packages wanting to use it. (full disclosure though: You could apply similar reasoning to log.Logger, which still makes me a bit sad for not being an interface…). I think it makes sense, to make this tradeoff for the specific cases. If you expect a lot of reimplementations of that interface and people wanting to operate on the interface in general, it makes sense to provide it only once. If your provided implementations don't share much code and are worthy of own-packaged-nes, do the encoding thing. There is this technical argument favoring writing the interface yourself though (where it makes sense), which is that two interfaces from different packages are different types, even if they share all methods, which will matter, if they in turn are to be used in interfaces or other type definitions (And before some zelot points me to it again: Yes, I know about #8082, yes, I agree it would be a good idea, but I'm also not optimistic that it'll happen, as it stands). On Mon, Nov 21, 2016 at 8:47 PM, Dave Cheney <d...@cheney.net> wrote: > My vote is for "in the package that needs them" > > > On Tuesday, 22 November 2016 02:30:21 UTC+11, Vorn Mom wrote: >> >> Sorry if it was asked before, but where should interfaces live? >> >> - In the package that contains an implementation of it. >> - In its own package. >> - or in the package that needs it. >> >> The standard library is not consistent. For example: >> >> - io.Writer is defined in a package that also has an implementation, >> io.PipeWriter. >> - Encoding is all interfaces, defering implementation to sub-packages. >> - database/sql returns a DB struct on Open() instead of an interface. >> >> Because Go interfaces are decoupled from implementation, I think it >> should be defined where it's needed. So I like having my own interface for >> DB that may only define a subset of what behaviors it provides. >> >> However, doesn't defining an interface that depends on other packages >> decrease cohesion and leaks the abstraction? For example, >> >> type interface DbQuery { >> QueryRow(query string, args ...interface{}) *sql.Row >> } >> >> This interface depends on sql.Row. This decreases cohesion because the >> interface is now defined across packages? >> >> -Vorn >> >> >> -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
