Best way to organize a Go interface

Question

Hey Everyone,

Its been a long time since I have programmed in C++, but I know that in C++ the classes are organized into .h files and .cpp files. Also many other languages benefit from splitting up code into logical groupings within a directory structure to improve organization.

Well I am trying to learn Go now and I was reading over the Go for C++ Programmers article when I came upon interfaces. The article explains that interfaces in Go essentially take the place of classes, and shows how to set them up pretty well.

What I am trying to figure out though is how should I organize an interface into files? For instance, should the interface be in one file while the implementation is in another?

myInterface.go

type myInterface interface {
    get() int
    set(i int)
}

myImplementation.go

type myType struct { i int }
func (p *myType) set(i int) { p.i = i }
func (p *myType) get() int { return p.i }

My code here may be wrong since I do not completely know what I am doing yet (and if I am wrong please correct me), but would this be the best way to set this up? Im having a very hard time trying to wrap my head around how to organize code in Go so any help is appreciated!

Metropolis

Answer 1

The Go programming language is not C++, nor is it C. Approach it like a new language. Go has no equivalent to header files. It has only a loose association with the C++ concept of classes. Since you are not an expert C++ programmer, ignore the Go For C++ Programmers article.

Start by reading A Tutorial for the Go Programming Language. Then read Effective Go. Browse through The Go Programming Language Specification, so you'll know where to look things up.

Go is open source, so look at real Go package documentation and source code.

To start, look at the time package documentation and source code, which was written by the authors of Go. They don't use separate files for interface declarations and implementations, so why do you want to? As you say yourself, you don't know what you are doing yet, so why not start by following the example set by experts?

Some of the motivation for the development of the Go programming language came from a desire to create language which was better than C and much simpler than C++. Taking into account the procedural characteristics (often C like) of Go, procedural design concepts such as coupling and cohesion are useful. These concepts are evident in the partitioning of the Go time package into multiple source files. Some class design concepts will be useful too, but remember, Go does not support inheritance.

As Nicklaus Wirth pointed out in his classic paper, Program Development by Stepwise Refinement, early drafts of a program are rarely ideal, perhaps even sloppy sometimes. Even the final version is rarely perfect. For example, the Go authors, after only a few months, recently rewrote the Go json package.

The design and implementation of the Go programming language lends itself to the use of many small functions. It favors succinct solutions. Of course, many of the functions are not exposed outside the package. Arbitrary limits on function size or number rarely work in any language.

Go programs are constructed by linking together packages. A package in turn is constructed from one or more source files that together declare constants, types, variables and functions belonging to the package and which are accessible in all files of the same package. Those elements may be exported and used in another package. Packages, The Go Programming Language Specification.

What do want your first Go package to do? Ask specific questions that can be answered, and provide details.

Answer 2

There is no need to put types and interfaces in separate files. The things exported from each package are what matters and you denote those by beginning the name with a capital letter. In C & co. what goes into a header file matters because that's the thing “imported” (included). In Go it's the package that is imported, and it doesn't matter how its contents are organised into different source files (it won't be visible to the importer anyhow).

My personal recommendation is to avoid creating unnecessary files. If the code is relatively short, keep it in one file. If it's long, then consider splitting off parts for which it feels natural to do so (e.g. interface + related functions that would be probably form a separate class if you were doing it in Java or C++). Don't split off anything just for the sake of separating definitions from code; it doesn't make sense in Go even though it does in C.