25

I have a short program in Go with the following files part of it. Program directory structure:

myprogram/
    main.go
    server.go
    routines.go
    structs.go

These different files contain different function. The structs.go file contains a list of structure type defined, and used in several files of my program. What I want to do, now is to split my program into package like in this example :

main/
    main.go // the main program
server/
    server.go // a package imported in main
routines/
    routines.go // a package imported in main

My problem, is that I do not know where to put structs.go because it contains structures used in several package, as in the 'main.go' code.

How to share efficiently this structs.go file ? Should I include it (via a symlink to the file) in each of the package I defined, i.e serverand routines and also in main ?

My method may be awkward because I'm a beginner in Go, and in programming generally.

ElieLie
  • 369
  • 1
  • 3
  • 6
  • There is no need to separate stuff into it's own package. Ask yourself: What actual benefit results from this split? And now compare to the costs. – Volker Feb 23 '16 at 12:01
  • The objective is to re-use some of these packages in others programs than `main`. – ElieLie Feb 23 '16 at 12:32

2 Answers2

20

Don't link files across packages, that's bad practice. For one, the code will be duplicated. For another, identifiers will be duplicated meaning to denote the same entities (e.g. type or function), but they will be distinct. E.g. if linked and structs.go would contain a type Response definition, you would have 2 distinct types server.Response and routines.Response giving just more confusion.

One solution would be to put structs.go into its own package, e.g. model, and all other packages relying on it can import it (e.g. your main, server and routines).

In a theoretical example: if package A imports package B and structs.go would be needed in both, then it could also be added to package B. If there would be a package C needing only structs.go, then again it would be wiser to create its own package model (so package C doesn't need to import / know about package B, only the new model package).

Also if noone else will use your package and it is not too complex, it might not worth the hassle to organize it into multiple packages.

icza
  • 389,944
  • 63
  • 907
  • 827
  • 1
    Ok, so you recommend me to create a package of structures ,e.g `model`. Thank you for this answer, I hope it's a good practice in Go. – ElieLie Feb 23 '16 at 12:15
  • 4
    As far as I know (and been told on IRC), go discourages from creating model packages. See: https://medium.com/@benbjohnson/standard-package-layout-7cdbc8391fc1 and https://rakyll.org/style-packages/ for just two examples – pandaadb Dec 11 '19 at 16:17
1

It is possible to define a type in one package only and to use it in other packages this way:

package one
type A struct{ B int }

Variant 1:

package two
. import "one"
var name A

Variant 2:

package two
import "one"
type A = one.A
var name A

I would prefer variant 2.

Thomas Höhenleitner
  • 99
  • 6