I searched around a bit but couldn't find any discussion on this.

What is recommended, giving an interface with a package, even if the
package doesn't use it itself, or let the callers define the interface?

My specific case is a thing A that exposes a couple methods and a Close().
Then thing B uses thing A but dynamically opens and closes them.

First instinct was that I could provide an interface Aer in the A package
that doesn't include the Close() and then B define an interface ACloser in
the B package as well as a ACreator which defines a Create() (ACloser,
So that is two new interfaces in B and an interface in A, and in my unit
tests it becomes a bit silly.

So this really boils down to, should we include Close() (and perhaps New())
in interfaces? And should the interfaces be in the calling code or
implementing code?

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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 1 of 4 | next ›
Discussion Overview
groupgolang-nuts @
postedFeb 1, '16 at 10:47p
activeFeb 4, '16 at 3:49p

2 users in discussion

Jonathan Gaillard: 2 posts Henry: 2 posts



site design / logo © 2022 Grokbase