Встраивание структур в Go: композиция, которую путают с наследованием

Что здесь на самом деле спрашивают

Лестница почти всегда такая:

1. «Есть ли в Go наследование?» — разминка; ответ «нет, есть встраивание» правильный, но ничего не объясняет.
2. «Что будет, если внешний тип объявит тот же метод, что и встроенный?» — здесь проверяют, понимает ли кандидат, что переопределения нет — есть сокрытие.
3. «Почему структура со встроенным типом не реализует интерфейс?» — про наборы методов, и это тот же вопрос, что в уроке о получателе.
4. «Что будет, если встроить два типа с одинаковым методом?» — правило глубины.
5. «Зачем встраивать интерфейс в структуру?» — и чем это опасно.
6. «Стоит ли встраивать sync.Mutex?» — про то, что встраивание публикует чужие методы.

Стержень у лестницы один: встраивание решает, какой путь к полю подставить в выражение, — и только это. Всё, что ведёт себя «не как наследование», из этой фразы и следует.

База: поле без отдельного имени

Спецификация определяет встраивание через имя, которое не пишут:

Имя у поля всё-таки есть — спецификация тут же уточняет, что им служит неквалифицированное имя типа. Logger встроен в Server, и к нему можно обратиться как s.Logger. Новое здесь другое: поля и методы Logger поднимаются — становятся доступны напрямую, без промежуточного имени:

type Logger struct{ prefix string }
 
func (l Logger) Log(msg string) string { return l.prefix + msg }
 
type Server struct {
    Logger
    name string
}

1) ПОДЪЁМ ПОЛЕЙ И МЕТОДОВ
─────────────────────────
  s.Log("старт")           -> "[api] старт"
  s.Logger.Log("старт")    -> "[api] старт"
  s.prefix                 -> "[api] "

s.Log — поднятый селектор: компилятор разрешает его в метод встроенного поля s.Logger, и результат тот же, что у явного s.Logger.Log. Такие поля и методы спецификация называет поднятыми.

Этого достаточно для ответа уровня Junior на вопрос «есть ли в Go наследование»: нет. Есть встраивание — поле без отдельного имени, чьи поля и методы поднимаются и вызываются напрямую. Это композиция: Server содержит Logger, а не является им. Уточнение для точности: именованное поле log Logger — тоже композиция; встраивание отличается от неё только подъёмом.

Одну таблицу стоит запомнить сразу — она отвечает, реализует ли внешний тип интерфейс; почему она такая, разобрано в Механизме 2:

Последние слова стоит произнести вслух, потому что на них держится весь следующий шаг. Передать Server туда, где ждут Logger, нельзя — это разные типы; передают s.Logger.

Механизм 1: у встраивания виртуального вызова нет

Вопрос, на котором заканчивается аналогия с наследованием. Base объявляет Name и Describe, причём Describe зовёт Name. Derived встраивает Base и объявляет свой Name:

type Base struct{}
 
func (Base) Name() string { return "Base" }
 
func (b Base) Describe() string { return "describe: " + b.Name() }
 
type Derived struct{ Base }
 
func (Derived) Name() string { return "Derived" }

В языке с виртуальными методами — в Java или в C++ с virtual — d.Describe() вернул бы «describe: Derived»: метод родителя вызвал бы переопределённый метод потомка. В Go:

2) У ВСТРАИВАНИЯ ВИРТУАЛЬНОГО ВЫЗОВА НЕТ
────────────────────────────────────────
  d.Name()                 -> "Derived"
  d.Describe()             -> "describe: Base"
  d.Base.Name()            -> "Base"
  Describe поднят из Base и получает Base, а не Derived:
  Name внутри него — Base.Name, что бы ни объявил внешний тип.

Объяснение — в той самой фразе про путь к полю. d.Describe() — это d.Base.Describe(). Получатель Describe — значение типа Base, и о том, что оно лежит внутри Derived, метод не знает. b.Name() внутри него — вызов на Base, выбранный при компиляции.

Внешний Name при этом не бесполезен: он прячет встроенный для всех, кто вызывает d.Name() снаружи. Это сокрытие имени, а не переопределение: оно меняет выбор пути в выражении, но не меняет, что делает код встроенного типа.

Если нужно именно то, что даёт наследование, — чтобы общий алгоритм звал переменную часть, — в Go это делают интерфейсом, переданным явно:

type Namer interface{ Name() string }
 
func DescribeAny(n Namer) string { return "describe: " + n.Name() }

8) ДИНАМИЧЕСКИЙ ВЫЗОВ — ЧЕРЕЗ ИНТЕРФЕЙС
───────────────────────────────────────
  DescribeAny(d)           -> "describe: Derived"

Динамическая диспетчеризация в Go есть, но живёт она в интерфейсах, а не во встраивании.

Механизм 2: встроен T или *T — разные наборы методов

Методы поднимаются не все и не всегда. Правило в спецификации короткое:

Для встроенного указателя правило щедрее:

Проверка на интерфейсе с методом, объявленным на *Store:

3) НАБОР МЕТОДОВ: ВСТРОЕН T ИЛИ *T
──────────────────────────────────
  ByValue{} (встроен Store)    реализует Saver: false
  &ByValue{}                   реализует Saver: true
  ByPointer{} (встроен *Store) реализует Saver: true
  &ByPointer{}                 реализует Saver: true

Это тот же механизм, что в уроке о получателе метода, — просто на один шаг дальше. Значение ByValue{}, положенное в интерфейс, — копия без адреса; у встроенного в него Store адреса тоже нет, и метод с получателем-указателем вызвать не на чем. У встроенного *Store указатель лежит в самом поле, и адрес для Save есть всегда.

Компилятор на попытку положить такое значение в интерфейс отвечает так:

ptrrecv:
  ./main.go:14:16: cannot use ByValue{} (value of struct type ByValue) as Saver value in variable declaration: ByValue does not implement Saver (method Save has pointer receiver)

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

Механизм 3: глубина — и когда одинаковые имена становятся ошибкой

Встроенные типы могут встраивать свои, и у каждого имени появляется глубина — сколько встроенных полей пройдено до него. Выбор пути решает одно правило:

Из первой половины — сокрытие. Внешнее поле на глубине 0 прячет встроенное на глубине 1:

4) ГЛУБИНА: ВНЕШНЕЕ ИМЯ ПРЯЧЕТ ВСТРОЕННОЕ
─────────────────────────────────────────
  o.ID                     -> "внешний"
  o.Inner.ID               -> "внутренний"

Из второй — неоднозначность. File встраивает Reader и Writer, у обоих есть Close. Объявить такой тип можно; ошибкой становится обращение к имени:

С обращением f.Close():
  # deepengineering/bench/goembed/ambiguous
  ./main.go:24:8: ambiguous selector f.Close

Без него (строка 24 закомментирована):
  собрано без ошибок

Но и без обращения неоднозначность не безобидна. При одинаковой наименьшей глубине ни один из кандидатов не становится поднятым Close — значит, метод Close интерфейса типом File не удовлетворён. Присваивание интерфейсу не собирается, хотя f.Close в файле нет, а проверка типа во время выполнения молча даёт false:

ambigiface:
  ./main.go:22:17: cannot use File{} (value of struct type File) as Closer value in variable declaration: File does not implement Closer (ambiguous selector File.Close)

10) НЕОДНОЗНАЧНОЕ ИМЯ И НАБОР МЕТОДОВ
─────────────────────────────────────
  any(File{}).(Closer)     -> реализует: false

Правило касается только наименьшей глубины. То же имя на разной глубине — не ошибка, а одинаковые имена на глубине 0 — уже ошибка объявления (ID redeclared): это два поля одной структуры, а не поднятые имена.

Это различие важно не только для экзамена. Оно значит, что неоднозначность может появиться в коде, который вы не трогали: если в новой версии библиотеки у одного из встроенных типов появится метод с тем же именем, что у другого, ваш вызов перестанет собираться — а проверка типа где-нибудь в другом пакете начнёт молча давать false. Явный путь — f.Reader.Close() — работает в обоих случаях.

Механизм 4: встроенный интерфейс — реализация, которая падает при вызове

Встроить можно не только структуру, но и интерфейс. Тогда внешний тип получает все методы интерфейса — и компилятор считает, что интерфейс реализован, даже если поле осталось nil:

type ReadCloser interface {
    Read() string
    Close() string
}
 
type fakeRC struct {
    ReadCloser
}
 
func (fakeRC) Read() string { return "данные" }

5) ВСТРОЕННЫЙ ИНТЕРФЕЙС, ОСТАВШИЙСЯ nil
───────────────────────────────────────
  rc.Read()                -> "данные"
  rc.Close()               -> паника: runtime error: invalid memory address or nil pointer dereference

Read объявлен в fakeRC и работает. Close поднят из поля ReadCloser, а поле — nil, и вызов падает. Компилятор при этом не возражал ни разу.

Применений у этого приёма два, и оба законные. Тестовая заглушка: интерфейс из десяти методов, а тесту нужен один — встраивают интерфейс и объявляют этот один. Если код под тестом позовёт другой, тест упадёт громко, а не пройдёт молча. Обёртка: встраивают настоящий объект (например, http.ResponseWriter) и объявляют свой вариант одного метода, а остальные идут насквозь. Опасен этот приём ровно тем, что видно в прогоне: обещание «реализует интерфейс» проверяется при компиляции, а выполняется только при вызове.

Механизм 5: что встраивание выносит наружу

Подъём работает для всех — в том числе для тех, кто пользуется вашим типом. Отсюда главный производственный риск встраивания: встроенный тип из чужого пакета продолжает меняться без вас. Новый экспортируемый метод в следующей версии зависимости сам собой становится частью API вашего типа; если такой же метод появится у другого встроенного типа, возникнет неоднозначность из Механизма 3, и тип молча перестанет удовлетворять интерфейсы с этим методом. Ни одна строка вашего кода при этом не меняется.

Встроенный sync.Mutex — частый приём «чтобы писать c.Lock()»:

type Cache struct {
    sync.Mutex
    data map[string]string
}

6) ЧУЖИЕ МЕТОДЫ В ПУБЛИЧНОМ API
───────────────────────────────
  методы *Cache: [Lock TryLock Unlock]

Ни одного из трёх методов Cache не объявлял, а любой код, получивший *Cache, может взять и отпустить его замок. Замок перестаёт быть деталью реализации. Поэтому мьютекс обычно кладут именованным полем — mu sync.Mutex: писать на три символа больше, зато снаружи его не видно. И копировать структуру со встроенным мьютексом нельзя так же, как с именованным, — это разобрано в уроке о sync и atomic.

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

7) JSON: ПОДЪЁМ И МОЛЧАЛИВЫЙ КОНФЛИКТ
─────────────────────────────────────
  два встроенных ID         {"Title":"report"}
  один из них с тегом       {"ID":2,"Title":"report"}

Audit и Owner оба несут поле ID, и в JSON не оказалось ни одного. Ни ошибки при кодировании, ни предупреждения — поле просто пропало из ответа API. Тег json:"ID" у одного из полей разрешает конфликт в его пользу — а для селектора тег ничего не меняет:

tagsel:
  ./main.go:18:18: ambiguous selector DocTagged{}.ID

Глубже: поднятый вызов от прямого не отличить — путь выбран при компиляции

Всё выше сводится к одному: путь к полю или методу выбирается при компиляции, по глубине. Для встроенной структуры во время выполнения нет ни поиска по цепочке «родителей», ни таблицы методов. Это видно и по цене:

  e.Rev()  прямой вызов                  2.18 нс
  c.Rev()  поднят из встроенного *Engine  2.14 нс
  кратность                              0.98

В замеренных конкретных вызовах на go1.24.7 поднятый и прямой пути не отличаются в пределах шума: c.Rev() и есть c.Engine.Rev(), и дополнительного поиска «по наследованию» во время выполнения нет. Это проверка здравого смысла на одной версии, а не гарантия языка в наносекундах. Оговорка одна: если встроен интерфейс, вызов через него — обычная интерфейсная диспетчеризация, как у любого поля интерфейсного типа.

Отсюда же сводная таблица, которую удобно держать в голове вместо слова «наследование»:

Как отвечать на собеседовании

Короткий ответ: наследования в Go нет. Есть встраивание — поле без имени, чьи поля и методы можно вызывать напрямую; s.Log() — сокращение для s.Logger.Log(). Это композиция: внешний тип содержит встроенный, а не является им, и метод встроенного типа работает со своим значением, а не с внешним.

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

На «а если внешний тип объявит тот же метод» покажите Describe. «Снаружи d.Name() вернёт внешний Name — он прячет встроенный. Но поднятый Describe, который зовёт Name, получит Base и вызовет Base.Name: в прогоне d.Describe() дал „describe: Base“. У встраивания виртуального вызова нет; если он нужен — интерфейс».

На «почему не реализует интерфейс» назовите правило набора методов. «Встроенный T поднимает методы с получателем *T только в набор *S. Значит, реализует интерфейс указатель на внешнюю структуру, а не значение».

На «два одинаковых метода» — правило глубины. «На наименьшей глубине — ошибка ambiguous selector при обращении; объявление законно, но поднятым не становится ни один кандидат, и метод интерфейса тип уже не удовлетворяет. Внешнее имя на меньшей глубине прячет встроенное».

На «зачем встраивать интерфейс» — заглушки и обёртки, и цена. «Компилятор считает интерфейс реализованным, а метод, который внешний тип не объявил, падает, если поле nil».

Про sync.Mutex и JSON — что выходит наружу. «Встроенный мьютекс публикует Lock и Unlock; поэтому его кладут полем mu. Одноимённые поля двух встроенных структур пропадают из JSON оба, без ошибки».

Дальше спросят

9) ВСТРОЕННЫЙ УКАЗАТЕЛЬ, ОСТАВШИЙСЯ nil
───────────────────────────────────────
  h.Ptr()  (получатель *T) -> "получатель nil, метод проверил и отработал"
  h.Val()  (получатель T)  -> паника: runtime error: invalid memory address or nil pointer dereference
  h.X      (поле)          -> паника: runtime error: invalid memory address or nil pointer dereference

Частые заблуждения

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона скрипта, а не назначен.

type Base struct{}

func (Base) Name() string       { return "Base" }
func (b Base) Describe() string { return "describe: " + b.Name() }

type Derived struct{ Base }

func (Derived) Name() string { return "Derived" }

d := Derived{}
fmt.Println(d.Name())
fmt.Println(d.Describe())
_, ok := any(ByValue{}).(Saver)
fmt.Println(ok)
b, _ := json.Marshal(Doc{Audit{1}, Owner{2}, "report"})
fmt.Println(string(b))

Derived
describe: Base
false
{"Title":"report"}

Derived
describe: Derived
false
{"Title":"report"}

Derived
describe: Base
true
{"ID":1,"Title":"report"}

Derived
describe: Derived
true
{"ID":2,"Title":"report"}

Проверка знаний