Il receiver di un metodo è il valore su cui opera, dichiarato prima del nome del metodo. Può essere un value receiver (opera su una copia) o un pointer receiver (opera sull'originale, può modificarlo). Scegliere correttamente è importante sia per la correttezza (mutazione) che per le prestazioni.
Counter { count }
Increment() {
c.count++
}
c := Counter{}
c.Increment()
fmt.Println(c.count)
Un value receiver riceve una copia della struct, quindi le modifiche non interessano l'originale — utile per metodi di sola lettura, ma un bug se intendevi mutare.
func (c *Counter) Increment() { // POINTER receiver — c points to the original
c.count++ // modifies the ACTUAL struct
}
c := Counter{}
c.Increment() // Go automatically takes &c
fmt.Println(c.count) // 1 — the original WAS modified
Un pointer receiver opera sulla struct effettiva, quindi può modificarla. Go prende automaticamente l'indirizzo (c.Increment() funziona anche su un valore).
Use a POINTER receiver when:
✓ The method needs to MODIFY the receiver (mutation)
✓ The struct is LARGE (avoid copying it on every call — performance)
✓ For CONSISTENCY (see below)
Use a VALUE receiver when:
✓ The method only READS, the type is small, and you want copy semantics
✓ The type is naturally a value (small structs, basic types)
// ✅ be consistent — if ANY method needs a pointer receiver, use pointer for ALL
func (c *Counter) Increment() { c.count++ }
func (c *Counter) Value() int { return c.count } // pointer too, for consistency
Mischiare value receiver e pointer receiver su un tipo causa problemi sottili — la convenzione è sceglierne uno (di solito pointer se un metodo muta) e usarlo per tutti i metodi.
type Incrementer interface { Increment() }
// if Increment has a POINTER receiver, only *Counter satisfies the interface, not Counter
var i Incrementer = &Counter{} // ✅ works
var j Incrementer = Counter{} // ❌ Counter (value) does NOT satisfy it
Questo è un gotcha comune: con metodi a pointer receiver, solo il tipo pointer soddisfa l'interfaccia.
La scelta tra value e pointer receiver è una decisione fondamentale di Go, spesso fraintesa, che influenza la correttezza, le prestazioni e la soddisfazione dell'interfaccia.
Il bug più comune è usare un value receiver quando intendevi mutare — la modifica interessa silenziosamente solo una copia, quindi il cambiamento "non persiste". I pointer receiver sono necessari per la mutazione e consigliati per struct grandi (per evitare copie costose a ogni chiamata).
La regola della coerenza (usare lo stesso tipo di receiver su tutti i metodi di un tipo) evita confusione, e la sottigliezza della soddisfazione dell'interfaccia (metodi a pointer receiver significano che solo il tipo pointer soddisfa l'interfaccia) è un gotcha classico che causa errori "does not implement interface".
Comprendere questi concetti è essenziale per scrivere Go corretto ed efficiente ed è tra gli argomenti pratici e di colloquio più comuni, poiché la scelta ha conseguenze non ovvie.