Структуры и методы в Go

Значение или указатель

Метод, объявленный как func (c Counter) Inc(), получает копию структуры. Он честно увеличивает поле - у копии. Копия умирает с концом метода, снаружи ноль. Хочешь менять оригинал - объявляй получатель указателем: func (c *Counter) Inc().

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

У мелких структур значение часто выгоднее: копия остаётся на стеке, не нагружает сборщик мусора и не даёт случайно разделить состояние между горутинами. Это не микрооптимизация, а нормальный дефолт.

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

получатель

аргумент метода перед его именем: (t T) для копии или (t *T) для адреса

Набор методов: почему тип «не реализует» интерфейс

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

Практическое следствие: если Inc объявлен на указателе, интерфейсу Incrementer удовлетворяет только *Counter. Присвоение значения даёт ошибку компиляции с довольно понятным текстом: Counter does not implement Incrementer (method Inc has pointer receiver). В интерфейс нужно класть &c.

Путаницу создаёт то, что прямой вызов c.Inc() при этом компилируется. Компилятор просто сам берёт адрес, потому что c - адресуемая переменная. При укладке в интерфейс он так не делает: туда копируется значение, и брать адрес уже не у чего.

// Хороший приём - проверка на этапе компиляции рядом с объявлением типа: var _ io.Writer = (*MyType)(nil). Строка ничего не создаёт и ничего не стоит, но ловит опечатку в имени метода и не тот получатель прямо в том файле, где тип живёт, а не в чужом пакете через месяц.

type Counter struct{ n int }
func (c *Counter) Inc() { c.n++ }

type Incrementer interface{ Inc() }

var c Counter
c.Inc()                    // компилируется: компилятор берёт &c сам
var i Incrementer = c      // ошибка компиляции:
// Counter does not implement Incrementer (method Inc has pointer receiver)
var j Incrementer = &c     // а так всё в порядке

набор методов

методы, которые учитываются при проверке соответствия интерфейсу

адресуемость

свойство переменной, у которой можно взять адрес; у временного значения его нет

Встраивание - это композиция

Поле без имени, только с типом, называется встраиванием. Поля и методы встроенного типа продвигаются на уровень внешнего и доступны напрямую, как свои: если в структуру встроен sync.Mutex, у неё появляются Lock и Unlock.

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

Отсюда типичное разочарование людей из мира классов: шаблонный метод, который вызывает переопределённый шаг, тут не работает. Нужное поведение получают интерфейсами - передают зависимость снаружи, а не наследуют.

// Встраивание интерфейса в структуру - отдельный полезный трюк: тип получает все методы интерфейса «бесплатно» (они делегируются во вложенное значение) и можно переопределить только нужные. Так пишут тестовые заглушки, не реализуя интерфейс из двадцати методов целиком.

встраивание

поле без имени; его поля и методы продвигаются на уровень внешнего типа

Теги полей: строка, которую никто не проверяет

Тег вроде json:"name,omitempty" - обычная строка, приклеенная к полю. Компилятор её не разбирает и не проверяет вообще. Читают её библиотеки во время работы, через рефлексию: кодировщик JSON берёт оттуда имя поля и флаги, драйверы баз - имена колонок, валидаторы - правила.

Отсюда первая ловушка: опечатка в теге ничего не ломает при сборке. Написал jsno:"name" - код собрался, тесты прошли, а поле уехало в JSON под именем по умолчанию, с заглавной буквы. Ловится это только глазами или линтером.

Вторая ловушка серьёзнее: поле с маленькой буквы не попадёт в JSON вообще, сколько тегов на него ни вешай. Рефлексия не видит неэкспортируемые поля, и кодировщик просто пройдёт мимо - молча, без ошибки.

// Поэтому структуры, которые ездят по сети или в базу, стоит держать отдельно от внутренних: у них другая задача и другие правила. Заодно перестаёшь случайно публиковать наружу поля, добавленные для внутренних нужд.

тег поля

строка с метаданными, которую читают библиотеки через рефлексию; компилятор её не проверяет

Как отвечать: «Почему метод не изменил структуру и когда брать указатель?»

Потому что получатель-значение - это копия. Метод func (c Counter) Inc() увеличивает поле у своей копии, копия умирает вместе с вызовом, снаружи ничего не меняется. Чтобы менять оригинал, получатель должен быть указателем. Второй повод взять указатель - крупная структура, копирование которой заметно на горячем пути. У мелких структур значение часто даже выгоднее: копия остаётся на стеке и не грузит сборщик мусора. И есть важное следствие для интерфейсов: в набор методов типа T входят только методы с получателем-значением, а у *T - и те, и другие. Поэтому если методы объявлены на указателе, интерфейсу удовлетворяет только указатель, и компилятор скажет прямо: method Inc has pointer receiver. Сбивает с толку, что прямой вызов c.Inc() при этом компилируется - там компилятор сам берёт адрес адресуемой переменной, а при укладке в интерфейс не берёт, потому что туда копируется значение. Практическое правило: не смешивать получатели у одного типа, и рядом с объявлением ставить проверку var _ I = (*T)(nil), чтобы несоответствие всплывало сразу.

Механизм копии назван прямо, критерий выбора дан по двум осям, следствие для интерфейсов объяснено вместе с причиной путаницы, и добавлены правило единообразия и способ поймать ошибку на компиляции.

На чём валят

• −Меняют поле в методе с получателем-значением и не понимают, почему снаружи ноль.
• −Кладут значение в интерфейс, когда методы объявлены на указателе.
• −Считают встраивание наследованием и ищут полиморфизм базового класса.
• −Смешивают получатели-значения и указатели у одного типа и ломают набор методов.
• −Делают опечатку в теге: сборка проходит, поле уезжает под именем по умолчанию.
• −Забывают заглавную букву в поле - оно молча исчезает из JSON.