Using interfaces for using methods in a different package - go

Question

I'm trying to understand the way interfaces can be used.
Below is a contrived example to demonstrate my question.
I have the main package, which instantiates a test database, and then passes this to a test server, where the server is then initialised.
Then there is a call to the server, which does a dummy database insert (using the dummy database dependency, passed on server initialisation).
main.go
package main
import (
"interfaces/database"
"interfaces/server"
)
func main() {
db := database.Start()
s := server.Start(db)
s.HandleInsert()
}
database.go
package database
import "fmt"
type Database struct {
pool string
}
func Start() *Database{
database := &Database{}
database.pool = "examplepool"
return database
}
func(db *Database) Select() {
fmt.Println("Running a Select")
}
func(db *Database) Insert() {
fmt.Println("Running an Insert")
}
func (db *Database) Delete() {
fmt.Println("Running a Delete")
}
server.go
package server
import "fmt"
type Database interface {
Select()
Insert()
Delete()
}
type Server struct {
server string
db Database
}
func Start(db Database) *Server {
fmt.Println("Created Server")
s := &Server{"exampleserver", db}
return s
}
func(s *Server) HandleInsert() {
s.db.Insert()
}
The thing is, in the server package, to make use of the database package, I've had to write out all the methods that the database object has. I've only got three methods, but my Database object could easily have more. This goes against Go's philosophy of having small interfaces. What am I missing here? I don't want to import the Database package into the Server package, as I want to encapsulate each package as much as possible.
Another question is, say I have other packages that want to make use of this Database package. Should they also contain a similar Database interface? Should I maybe have a package called "interfaces" which contains the Database interface, that can then be imported?
The idea for the layout of this code came from this video: https://youtu.be/rWBSMsLG8po

Answer 1

At first glance, I'd say you're doing things in the idiomatic golang way:
Return the type (database Start returns *Database, as it should)
The package defines interfaces for its dependencies (as you're doing)
The size of the interface isn't determined by what a given type exports (i.e. what methods your database.Database type implements), but rather what functionality you need. If your server package only ever needs to use Select, Insert, and Delete, then that's what the interface should be. The type you're passing to the server package could implement SelectNASASecretLizardFiles, but if you're not using it, the server package doesn't have to know the method exists. The server.Database interface remains as simple as it is now.
That's essentially what a small interface means. Golang interfaces are implemented implicitly (sometimes people call it ducktype interfaces). Any type that implements the 3 methods you defined in server.Database can be used as a dependency. This makes your packages really easy to unit-test (mocking is trivial).
The "downside" can be that, if you have several packages depending on the Database type, you can end up with duplicate definitions of the same interface. However, if one of the packages requires access to an additional function (or doesn't need to use the Insert method), changing the interface for that package doesn't affect any of the other packages. This fits with the whole concept of golang packages being self-contained.
In your particular case, though, I think there's room for a judgement call. If you're interfacing with a DB of sorts, I think it's a fair assumption to make that most, if not all, packages will all need to be able to select data. It's common to see a small, base interface defined in a common package:
|
|-- server
| |
| |--> dependencies.go (defines Databse interface for server pkg)
|
|-- foo
| |
| |--> dependencies.go (defines Database interface for this package)
|
|-- common (bad package name, but self explanatory)
| |
| |--> database.go (defines common subset of database interfaces)
Where the interfaces look like this:
package common
type DB interface {
// don't return a slice of maps, this is just an example
Select(query string, args ...interface{}) (rows []map[string]interface{}, err error)
Close() error
}
package server
import "your.project/common"
type Database interface {
common.DB // embedded common interface
Insert(query string, vals ...interface{}) error
Delete(query, id string) error
}
This is a common way to structure your code, while ensuring easy mocking and testing.
Speaking of mocking/testing, just a tip, but have a look at a tool called mockgen. You can have mocks for unit tests generated for your interfaces per-package by adding a single comment like this:
package server
import "your.project/common"
//go:generate go run github.com/golang/mock/mockgen -destination mocks/db_mock.go -package mocks your.project/server Database
type Database interface {
common.DB // embedded common interface
Insert(query string, vals ...interface{}) error
Delete(query, id string) error
}
Running go generate will spit out the mocks you can then import in your unit tests.
Other comments
Something I couldn't help notice is that your database package declares a type called Database. Why is the type exported? and why does it have the same name as the package? Using a type called database.Database is just code smell. Stuttering names should be avoided. Perhaps calling the handle Handle or Conn makes more sense: db.Handle or db.Conn is much more descriptive of what you're actually dealing with, and it's shorter to type.
The function to get the DB connection is also weirdly named (Start). It's a constructor function, so I think it'd make more sense to call it New, resulting in the code:
db := database.New()