Come dice il titolo, l'accesso ai campi della struct pubblica è più idiomatico in Go di getter e setter? Non porterebbe a violare l'incapsulamento dei dati, anche i campi pubblici in altri linguaggi OO come Java sono disapprovati.
Questa risposta afferma anche che getter e setter non sono idiomatici in Go.
L'uso della parola chiave struct (anziché class ) significa che è pensato per essere usato come le strutture in stile C (POD)?
L'articolo Vai efficace sul sito web ufficiale parla i getter e i setter stanno bene e ha anche delle linee guida su come nominarle:
Go doesn't provide automatic support for getters and setters. There's nothing wrong with providing getters and setters yourself, and it's often appropriate to do so, but it's neither idiomatic nor necessary to put
Getinto the getter's name. If you have a field called owner (lower case, unexported), the getter method should be calledOwner(upper case, exported), notGetOwner. The use of upper-case names for export provides the hook to discriminate the field from the method. A setter function, if needed, will likely be calledSetOwner. Both names read well in practice:owner := obj.Owner() if owner != user { obj.SetOwner(user) }
I campi privati e i getter pubblici sono utili per garantire gli invarianti di oggetti poiché puoi impedire alle persone di utilizzare gli interni dell'oggetto.
Poiché i setter eseguono le mutazioni, devi ovviamente stare attento. Le mutazioni non funzionano bene con aliasing perché una mutazione in un posto può influenzare il codice da qualche altra parte, e questo è particolarmente importante in contesti concomitanti che sono molto diffusi in Go.
Inoltre, i valori sono spesso copiati in Go (simile alle strutture in C e C #), quindi una chiamata setter che dovrebbe avere un effetto in qualche punto potrebbe non avere quell'effetto, che è un altro motivo per stare attenti quando si tratta di setter.