Tags: #go #guide
Information was pulled from https://medium.com/@kent.rancourt/go-pointers-when-to-use-pointers-4f29256ddff3
an unrelated comment would be, from a code design perspective, functions should not dip inside of data structures to access nested fields (I’ve seen this done to access a pointer to a struct): law of demeter.
For components with great importance, we should control the terms on which others interact with them. To do this, create an exported interface with a non-exported implementation, where pointers to the component in question implement the interface.
package main
import (
"fmt"
)
type S struct {
// ...
}
type Cache interface {
Add(key string, val S)
Get(key string)
Clear()
}
type cache struct {
foo string
bar int
}
func NewCache() Cache { // <--- This is what the caller sees
return &cache{"beep", 456} // <--- It's a pointer, but they don't need to know
}
func (c *cache) Add(key string, val S) {
// ...
}
func (c *cache) Get(key string) {
// ...
}
func (c *cache) Clear() {
// ...
}
func main() {
c := NewCache()
fmt.Printf("%+v\n", c) // <--- caller can see the structure &{foo:beep bar:456}
fmt.Printf("%+v\n", c.foo) // <--- but they can't interact with it (compile time error: c.foo undefined (type Cache has no field or method foo))
}