The interface I'm speaking of can be found here[1] on Github. I like your idea of composing interfaces. Most all of my operations fall into groups based on what kind of object they can operate on, so I could have interfaces for each kind and perhaps a master interface composed of every other interface. That would certainly make mocking these interfaces a less tedious task.
[1] https://github.com/velovix/snoreslacks/blob/c519af04946cc466280b8b364212d63ff0768f65/database/database.go#L66 On Monday, June 27, 2016 at 2:54:54 PM UTC-7, Chad wrote: > > What does the interface look like currently? > > On Monday, June 27, 2016 at 10:54:31 PM UTC+2, Tyler Compton wrote: >> >> Right now, I have a web server with an interface that defines methods for >> every kind of database read/write operation my application has. >> > Any example ? > > >> Unsurprisingly, it's pretty large for a Go interface at around 30 >> methods. I originally did this because I wanted to be able to support >> multiple implementations of my database layer, but now it's only so that I >> can mock out this functionality for testing, which is still important to me. >> >> This works fine, but it doesn't /feel/ right, whatever that means. As the >> proverb goes, "the bigger the interface, the weaker the abstraction." To be >> fair, I'm not really going for a lot of abstraction here. The only objects >> that should implement this interface would be geared very heavily towards >> my needs. Maybe that's where I went wrong. >> >> Is there a more idiomatic way I could be doing this? >> > > Interfaces are composable so you could probably make a slight refactor > where you assemble methods by usage. It may help keep things clearer. > -- 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.
