Een methode's receiver is de waarde waarop het werkt, gedeclareerd vóór de methodenaam. Het kan een value receiver zijn (werkt op een kopie) of een pointer receiver (werkt op het origineel, kan dit aanpassen). Het juiste kiezen is belangrijk voor zowel correctheid (mutatie) als prestaties.
Counter { count }
Increment() {
c.count++
}
c := Counter{}
c.Increment()
fmt.Println(c.count)
Een value receiver krijgt een kopie van de struct, dus wijzigingen beïnvloeden het origineel niet — nuttig voor read-only methoden, maar een bug als je wilde muteren.
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
Een pointer receiver werkt op de daadwerkelijke struct, dus het kan deze aanpassen. Go neemt automatisch het adres (c.Increment() werkt ook op een waarde).
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
Mengeling van value en pointer receivers op één type veroorzaakt subtiele problemen — de conventie is om er één te kiezen (meestal pointer als een methode muteert) en deze voor alle methoden te gebruiken.
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
Dit is een veel voorkomende valkuil: met pointer-receiver methoden voldoet alleen het pointer-type aan de interface.
De keuze tussen value en pointer receiver is een fundamenteel, vaak verkeerd begrepen Go-besluit dat correctheid, prestaties en interface-satisfactie beïnvloedt.
De meest voorkomende bug is het gebruik van een value receiver als je wilde muteren — de wijziging beïnvloedt geruisloos alleen een kopie, dus de verandering "blijft niet hangen". Pointer receivers zijn vereist voor mutatie en aanbevolen voor grote structs (om dure kopieën bij elke aanroep te voorkomen).
De consistentieregel (gebruik hetzelfde receiver-type in alle methoden van een type) voorkomt verwarring, en de interface-satisfactie subtiliteit (pointer-receiver methoden betekenen dat alleen het pointer-type aan de interface voldoet) is een klassieke valkuil die "does not implement interface"-fouten veroorzaakt.
Begrip van deze aspecten is essentieel voor het schrijven van correct en efficiënt Go-code en behoort tot de meest voorkomende praktische en interviewonderwerpen, omdat de keuze niet-voor-de-hand-liggende gevolgen heeft.