Встраивание структур в Go: разбираем на живом примере

Зачем вообще встраивание, если есть интерфейсы

Go не поддерживает наследование классов. Вместо этого язык предлагает композицию — и встраивание структур (struct embedding) делает её синтаксически дешёвой. Вы объявляете поле без имени, и все его методы и поля «всплывают» на уровень внешней структуры. Код выглядит так, будто внешний тип унаследовал поведение внутреннего. Но ресивер метода остаётся прежним — и именно здесь начинаются сюрпризы.

Что нужно, чтобы повторить примеры

• Go 1.21+ (примеры проверены на 1.22, но совместимы с 1.21).
• Любой редактор с поддержкой Go — VS Code с расширением Go или GoLand.
• Файл main.go в пустом модуле: go mod init embedding-demo.

Живой пример: логгер с метриками

Допустим, у вас есть простой структурный логгер, и вы хотите добавить к нему подсчёт записанных сообщений. Очевидное решение — встроить логгер в новую структуру.

Базовый логгер

package main

import (
	"fmt"
	"time"
)

// Logger — минимальный структурный логгер.
type Logger struct {
	Prefix string
}

// Log выводит сообщение с префиксом и временной меткой.
func (l *Logger) Log(msg string) {
	fmt.Printf("[%s] %s: %s\n", time.Now().Format(time.TimeOnly), l.Prefix, msg)
}

// SetPrefix меняет префикс и возвращает логгер для цепочки вызовов.
func (l *Logger) SetPrefix(p string) *Logger {
	l.Prefix = p
	return l
}

Проверка: вызовите Logger{Prefix: "app"}.Log("started") — в консоли появится строка вида [15:04:05] app: started.

Встраиваем в CountingLogger

// CountingLogger считает, сколько раз вызван Log.
type CountingLogger struct {
	*Logger          // встроенная структура — без имени поля
	Count int
}

// Log переопределяет метод встроенного логгера.
func (cl *CountingLogger) Log(msg string) {
	cl.Count++
	cl.Logger.Log(msg) // явный вызов метода встроенной структуры
}

func main() {
	cl := &CountingLogger{
		Logger: &Logger{Prefix: "metrics"},
	}

	cl.Log("request handled")
	cl.Log("request handled")
	fmt.Printf("total messages: %d\n", cl.Count) // 2

	// SetPrefix доступен без явного делегирования
	cl.SetPrefix("updated")
	cl.Log("new prefix works")
	fmt.Printf("total messages: %d\n", cl.Count) // 3
}

Запустите go run main.go. Должны увидеть три строки лога и два счётчика: 2 и 3.

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

Три ключевых момента, которые отличают embedding от наследования в классических ООП-языках:

1. Промотирование, а не переопределение. Когда CountingLogger объявляет свой Log, он не «переопределяет» метод родителя — он затеняет промотированный метод. Компилятор просто выбирает ближайший по глубине.
2. Ресивер не меняется. Внутри Logger.Log значение l — это *Logger, а не *CountingLogger. Встроенная структура ничего не знает о внешней. Полиморфизма «вверх» нет.
3. Промотируются и поля. Обращение cl.Prefix — это синтаксический сахар для cl.Logger.Prefix. Если у CountingLogger появится своё поле Prefix, промотирование отключится — молча, без предупреждения компилятора.

Встраивание — это автоматическое делегирование. Вы получаете удобный синтаксис, но не получаете позднее связывание. Если вам нужен полиморфизм — используйте интерфейсы, а не embedding.

Ловушка с SetPrefix: цепочка возвращает не тот тип

Обратите внимание на SetPrefix. Он возвращает *Logger, а не *CountingLogger. Если написать:

cl.SetPrefix("oops").Log("this bypasses counting")
fmt.Printf("total messages: %d\n", cl.Count) // Count НЕ увеличился

Вызов Log после SetPrefix уходит в Logger.Log — счётчик не затронут. Это классическая ошибка: цепочка вызовов «теряет» внешний тип, потому что встроенный метод ничего о нём не знает.

Как исправить

Два варианта:

• Переопределить SetPrefix на уровне CountingLogger, чтобы он возвращал *CountingLogger.
• Отказаться от цепочки и вызывать SetPrefix отдельной строкой — менее красиво, зато тип не ускользает.

Когда embedding помогает, а когда мешает

Конфликт имён: тихая бомба

Если встроить две структуры, у которых есть метод с одинаковым именем, код скомпилируется. Ошибка возникнет только при попытке вызвать этот метод — и только если вы не разрешите неоднозначность явным указанием пути. Это значит, что вы можете добавить второе встраивание, пройти go build и узнать о проблеме в рантайме через месяц, когда кто-то наконец вызовет конфликтный метод.

type A struct{}
func (A) Do() { fmt.Println("A") }

type B struct{}
func (B) Do() { fmt.Println("B") }

type C struct {
	A
	B
}

// c := C{}
// c.Do()      // ошибка компиляции: ambiguous selector c.Do
// c.A.Do()    // работает
// c.B.Do()    // работает

Линтер go vet это не ловит. Если хотите ловить такие ситуации раньше, стоит посмотреть на правила в golangci-lint — например, govet в расширенном режиме или сторонние линтеры для embedding-конфликтов.

Embedding и интерфейсы: бесплатная реализация

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

Проверить, какие интерфейсы реализует тип, можно через go doc или в IDE. Привычка ревьюить промотированные методы после добавления embedding спасает от неожиданных совпадений.

Промотирование (promotion) — механизм, при котором методы и поля встроенного типа становятся доступны на внешнем типе без явного делегирования. Термин из спецификации Go, раздел «Struct types».

Что делать дальше

• Пройдитесь по своему коду и найдите все встраивания. Для каждого ответьте: зачем встроено, а не объявлено именованным полем? Если ответ «так короче» — это повод задуматься.
• Проверьте, не возвращает ли встроенный тип *self — это источник ловушки с цепочками.
• Добавьте в CI линтер golangci-lint с включённым govet — он поймает хотя бы часть конфликтов.
• Прочитайте раздел спецификации Go Struct types — там формально описаны правила промотирования и разрешения конфликтов имён. Это два экрана текста, но они закрывают все крайние случаи.