Golang Structures & Concepts

There are packages, structs, functions, files, and interfaces.

All files belong to a single package. A package may have many files, functions (and methods), interfaces, and structs.

Functions and structs may be exported (their names start with an uppercase letter). Interfaces are always exported (?).

Any file within a package may reference a function defined in another file within that same package—regardless of if the function is exported or not. This goes for structs (including their unexported fields) and top-level variables as well.

Interfaces define a set of methods and their signatures. Structs are the only concept that can implement an interface, which is done by defining each interface method as operating on a struct (the struct type is written inside a parenthesis before the method signature, this is called the receiver). There is no explicit implements keyword; if a struct defines all of the methods declared by an interface, the interface has been implemented.

Unexported structs are to be regarded as private units of organization; ways to pass around data easily within that package. Private structs are useful for reducing boilerplate by implementing common interfaces & using the struct’s encapsulated data in the method implementations.

Packages can be regarded as a logical unit of organization; a separation of concerns. One package should take care of only one type of problem, leaving other problems to be solved by other packages. Files can be regarded as practical units of separation, splitting up related package-level logic into smaller chunks for easy reasoning. From an API-level, it does not matter if a package is composed of 1000 files or 1 file, all that matters is what functions and structs are exported.