Le récepteur d'une méthode est la valeur sur laquelle elle opère, déclaré avant le nom de la méthode. Il peut s'agir d'un récepteur par valeur (opère sur une copie) ou d'un récepteur par pointeur (opère sur l'original, peut le modifier). Le choix correct importe à la fois pour la justesse (mutation) et les performances.
Counter { count }
Increment() {
c.count++
}
c := Counter{}
c.Increment()
fmt.Println(c.count)
Un récepteur par valeur reçoit une copie de la structure, donc les modifications n'affectent pas l'original — utile pour les méthodes en lecture seule, mais un bug si vous aviez l'intention de muter.
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 récepteur par pointeur opère sur la structure réelle, donc il peut la modifier. Go prend automatiquement l'adresse (c.Increment() fonctionne même sur une valeur).
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
Mélanger récepteurs par valeur et par pointeur sur un même type cause des problèmes subtils — la convention est d'en choisir un (généralement pointeur si une méthode mute) et de l'utiliser pour toutes les méthodes.
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
C'est un piège courant : avec des méthodes à récepteur par pointeur, seul le type pointeur satisfait l'interface.
Le choix entre récepteur par valeur ou par pointeur est une décision Go fondamentale et souvent mal comprise qui affecte la justesse, les performances et la satisfaction d'interface.
Le bug le plus courant est d'utiliser un récepteur par valeur quand vous aviez l'intention de muter — la modification affecte silencieusement une copie seulement, donc le changement « ne persiste pas ». Les récepteurs par pointeur sont nécessaires pour la mutation et recommandés pour les grandes structures (pour éviter des copies coûteuses à chaque appel).
La règle de cohérence (utiliser le même type de récepteur pour toutes les méthodes d'un type) évite la confusion, et la subtilité de satisfaction d'interface (les méthodes à récepteur par pointeur signifient que seul le type pointeur satisfait l'interface) est un piège classique qui cause des erreurs « does not implement interface ».
Comprendre ces points est essentiel pour écrire du Go correct et efficace et figure parmi les sujets les plus courants en pratique et en entretien, puisque le choix a des conséquences non évidentes.