Esiste un modo efficace per condividere la struttura tra i pacchetti golang?

Question

Ho un breve programma in Go con i seguenti file parte di esso. Programma struttura di directory:

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

Questi file contengono diversi funzione diversa. Il file structs.go contiene un elenco di tipo di struttura definito e utilizzato in diversi file del mio programma. Quello che voglio fare, ora è quello di dividere il mio programma nel pacchetto come in questo esempio:

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

Il mio problema, è che io non so dove mettere structs.go perché contiene strutture utilizzate in vari il pacchetto, come in il codice 'main.go'.

Come condividere in modo efficiente questo file structs.go? Dovrei includerlo (tramite un link simbolico al file) in ognuno dei pacchetti che ho definito, cioè server e routines e anche in main?

Il mio metodo può essere scomodo perché sono un principiante in Go e in programmazione in generale.

Answer 1

Non collegare i file tra pacchetti, è una cattiva pratica. Per uno, il codice sarà duplicato. Per un altro, gli identificatori saranno duplicati nel senso per indicare le stesse entità (ad esempio, tipo o funzione), ma saranno distinti. Per esempio. se collegato e structs.go conterrebbe una definizione type Response, avresti 2 tipi distinti server.Response e routines.Response dando solo più confusione.

Una soluzione sarebbe inserire structs.go nel proprio pacchetto, ad es. model e tutti gli altri pacchetti che si basano su di esso possono importarlo (ad esempio il tuo main, server e routines).

In un esempio teorico: se la confezione pacchetto A importazioni B e structs.go sarebbero necessari in entrambi, allora potrebbe anche essere aggiunto al pacchetto B. Se ci fosse un pacchetto C che necessiti solo di structs.go, sarebbe di nuovo più saggio creare il proprio pacchetto model (quindi il pacchetto C non ha bisogno di importare/sapere pacchetto B, solo il nuovo pacchetto model).

Anche se nessun altro utilizzerà il pacchetto e non è troppo complesso, potrebbe non valere la pena di organizzarlo in più pacchetti.