When and why to return an interface in Golang?

Question

Example code:

type IClient interface {
    UploadFile(sourcePath, host string) error
    CopyFile(sourcePath, destPath string) error
    DeleteFile(sourcePath, option string) error
    GetChecksum(sourcePath string) (*string, error)
    GetSize(sourcePath string) (*float32, error)
}

type FileWorker struct {
    Extension string
    Host string
}

func NewFileWorker(fileExtension, host string) IClient {
    var fileWorker = &FileWorker {
        Extension: extension,
        Host: host,
    }
    return fileWorker
}

//NOTE: type FileWorker is the receiver of all methods implementing the IClient interface

I have seen other "New" (or "Get") function returning interface like above. But it does not actually return the interface, but instead a struct that implements said interface. In turn, that struct type is the receiver of various methods implementing said interface.

Question: When and why do we return interfaces? Currently I see this is a roundabout way of doing things, resulting in one having to trace back through multiple files while trying to understand some codes.

Answer 1

Interfaces are a way to achieve code reuse. Often times, what matters is not what an object is, but what it does. Consider the following method:

func Grade(questions []MultipleChoiceQuestion) {
    total := len(questions)
    correct := 0
    for _, q := range questions {
        if q.Test() {
            correct++
        }
    }
    return correct / total
}

The function Grade takes in a collection of questions and grades the user's answers.

What if we wanted to add true or false questions? Right now Grade only accepts MultipleChoiceQuestions, which means that we would have to make a whole new function, say GradeTrueOrFalse(questions []TrueOrFalseQuestions) in order to have a test with true or false questions. Furthermore, we would be unable to have a test composed of both multiple choice and true or false questions.

However, we should be able to copmbine questions in a single test. The original function doesn't care about what kind of question it is, only that the question can Test() the user's answer. This is where interfaces come in.

By abstracting away the Test method into an interface we can use Grade for any kind of question.

type Tester interface {
    Test() bool
}

type MultipleChoiceQuestion struct

func (q MultipleChoiceQuestion) Test() bool {
    // implementation...
}

type TrueOrFalseQuestion struct

func (q TrueOrFalseQuestion) Test() bool {
    // implementation...
}

func Grade(questions []Tester) {
    total := len(questions)
    correct := 0
    for _, q := range questions {
        if q.Test() {
            correct++
        }
    }
    return correct / total
}

Now Grade can take in any kind of question. Furthermore, questions []Tester can be a mix of multiple choice and true or false questions.

When used properly, you should rarely have to perform a type assertion or "trace back through multiple files" to understand what is going on.