Menu
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.
946
Go export struct Struct names and fields starting with a small letter are visible only inside their package. We create a new Go module with the go mod init command. This is the project structure. The Name and Occupation fields of the User struct are exported, while the age field is not.
You should prefix your import in main.go with: MyProj , because, the directory the code resides in is a package name by default in Go whether you're calling it main or not. It will be named as MyProj . package main just denotes that this file has an executable command which contains func main() .
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.
177
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
