Стоит ли использовать Reciever как указатель?

Критерии выбора между ресивером-значением и ресивером-указателем

Однозначного ответа "всегда использовать указатель" не существует, так как выбор зависит от конкретных требований к типу и его использованию. Вот основные критерии, которые я применяю на практике:

Когда использовать ресивер-указатель (pointer receiver)

1. Для модификации состояния структуры Когда метод должен изменять поля структуры, ресивер должен быть указателем:

type Counter struct {
    value int
}

// Изменяет состояние - только через указатель
func (c *Counter) Increment() {
    c.value++
}

func (c *Counter) Value() int {
    return c.value
}

2. Для избежания копирования больших структур Для структур значительного размера использование указателя предотвращает дорогостоящее копирование:

type LargeStruct struct {
    data [10000]int
}

// Эффективно - не копирует 10000 элементов
func (ls *LargeStruct) Process() {
    // работа со структурой
}

3. При реализации интерфейсов с методами-указателями Если хотя бы один метод типа имеет ресивер-указатель, для реализации интерфейса все методы должны быть согласованы:

type Mutable interface {
    Update()
}

// Правильно - оба метода с ресивером-указателем
type MyType struct{}

func (m *MyType) Update() {}
func (m *MyType) Other() {}

4. Для обеспечения nil-безопасности (в отдельных случаях) Методы с ресивером-указателем могут безопасно работать с nil:

type List struct{}

func (l *List) IsEmpty() bool {
    return l == nil
}

var lst *List // nil
fmt.Println(lst.IsEmpty()) // true

Когда использовать ресивер-значение (value receiver)

1. Для неизменяемых (immutable) типов Если тип предназначен быть неизменяемым, используйте ресивер-значение:

type Point struct {
    X, Y float64
}

// Возвращает новую точку, не изменяя оригинал
func (p Point) Move(dx, dy float64) Point {
    return Point{p.X + dx, p.Y + dy}
}

2. Для маленьких структур, где копирование дёшево Обычно я устанавливаю границу в 3-4 поля простых типов:

type RGB struct {
    R, G, B uint8
}

// Копирование 3 байтов дешевле работы с указателем
func (c RGB) Invert() RGB {
    return RGB{255 - c.R, 255 - c.G, 255 - c.B}
}

3. Для встроенных типов и псевдонимов типов Для базовых типов предпочитаю ресивер-значение, если нет необходимости в модификации:

type Celsius float64

func (c Celsius) ToFahrenheit() Fahrenheit {
    return Fahrenheit(c*9/5 + 32)
}

4. При работе с конкурентностью для thread-safety Ресивер-значение по умолчанию потокобезопасен для чтения:

type Config struct {
    timeout int
}

// Безопасно для конкурентного чтения
func (c Config) Timeout() int {
    return c.timeout
}

Важное правило согласованности

Всегда сохраняйте единообразие в рамках одного типа. Если один метод использует ресивер-указатель, все методы этого типа должны использовать указатель (за редкими исключениями, продиктованными семантикой). Это предотвращает путаницу при использовании типа:

// ❌ Плохо - смешанный подход
type User struct {
    name string
}

func (u User) Name() string { return u.name }
func (u *User) SetName(n string) { u.name = n } // Несогласованно!

// ✅ Хорошо - единый подход
type User struct {
    name string
}

func (u *User) Name() string { return u.name }
func (u *User) SetName(n string) { u.name = n }

Практические рекомендации

1. Начинайте с ресивера-значения для простых структур, переходите на указатели только при необходимости
2. Профилируйте производительность при сомнениях - преждевременная оптимизация может усложнить код
3. Документируйте семантику - если тип должен быть immutable, сделайте это явным через ресивер-значение
4. Тестируйте edge cases - особенно при работе с nil и конкурентностью

В кодовых базах, где я работал, мы обычно устанавливали соглашение: использовать ресивер-указатель по умолчанию для структур, а ресивер-значение - для маленьких или неизменяемых типов. Это создавало баланс между производительностью и ясностью кода.

Самый важный аспект - смысловая корректность: метод должен отражать то, что он делает с объектом. Если он меняет состояние - указатель, если возвращает новое значение - значение. Следуя этой логике, вы сделаете ваш код более понятным и предсказуемым для других разработчиков.