Встраивание структур в Golang: embedding и продвигаемые методы

Встраивание в одном примере

Поле с типом, но без имени, называется встроенным. Поля и методы встроенного типа становятся доступны прямо на внешнем типе.

package main

import "fmt"

type User struct {
	Name  string
	Email string
}

func (u User) Greet() string {
	return "Hi, I'm " + u.Name
}

type Admin struct {
	User  // embedded: no field name
	Level int
}

func main() {
	a := Admin{
		User:  User{Name: "Ana", Email: "ana@example.com"},
		Level: 2,
	}

	fmt.Println(a.Name)       // promoted field
	fmt.Println(a.Greet())    // promoted method
	fmt.Println(a.User.Email) // the explicit path still works
	fmt.Printf("%+v\n", a)
}

Вывод:

Ana
Hi, I'm Ana
ana@example.com
{User:{Name:Ana Email:ana@example.com} Level:2}

Имя встроенного поля совпадает с именем его типа, User. Так к нему обращаются в литералах (User: User{...}) и когда нужно само внутреннее значение (a.User). Продвинутое поле нельзя задать в литерале по короткому имени: Admin{Name: "Ana"} не компилируется с ошибкой unknown field Name in struct literal of type Admin.

Продвинутые методы удовлетворяют интерфейсам

Продвижение добавляет методы встроенного типа в набор методов внешнего. Поэтому внешний тип удовлетворяет всем интерфейсам, которым удовлетворяет внутренний.

package main

import "fmt"

type Logger struct {
	prefix string
}

func (l *Logger) Log(msg string) {
	fmt.Println(l.prefix + msg)
}

type Service struct {
	*Logger // embedded pointer
	name    string
}

type Loggable interface {
	Log(string)
}

func main() {
	svc := &Service{
		Logger: &Logger{prefix: "[billing] "},
		name:   "billing",
	}
	svc.Log("started")

	var l Loggable = svc // *Service has Log through the embedded *Logger
	l.Log("via interface")
}

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

У встраивания указателя есть цена: указатель может быть nil. Service{} без Logger компилируется, а svc.Log(...) затем паникует.

Встраивание не наследование

Встраивание похоже на создание подкласса, но три вещи работают иначе, чем в Java или Python.

Внешний тип не является внутренним. Admin не является User. Функция, принимающая User, не примет Admin; передайте a.User.

Виртуальной диспетчеризации нет. Продвинутый метод выполняется на встроенном значении и ничего не знает о внешнем типе. Если он вызывает другой метод, то вызывает версию своего типа, даже когда во внешнем типе есть метод с тем же именем.

package main

import "fmt"

type Animal struct{}

func (Animal) Sound() string { return "..." }

func (a Animal) Speak() string {
	return "The animal says " + a.Sound() // always Animal.Sound
}

type Dog struct {
	Animal
}

func (Dog) Sound() string { return "woof" }

func main() {
	d := Dog{}
	fmt.Println(d.Sound()) // Dog's own method shadows the promoted one
	fmt.Println(d.Speak()) // promoted Speak calls Animal.Sound, not Dog.Sound
}

Вывод:

woof
The animal says ...

В языке с классами Speak напечатал бы «woof». В Go d.Speak() это сокращение для d.Animal.Speak(), и получателем этого вызова является Animal. Если нужно поведение, зависящее от типа, используйте интерфейс: передайте Sounder в код, которому он нужен.

Внутренний тип не знает, что его встроили. super нет. Чтобы расширить продвинутый метод, определите на внешнем типе метод с тем же именем и явно вызовите внутренний:

func (a Admin) Greet() string {
	return a.User.Greet() + " (admin)"
}

Конфликты имён и затенение

Поле или метод внешнего типа затеняет продвинутое имя с тем же названием, как Dog.Sound выше. Побеждает менее глубокое имя.

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

package main

import "fmt"

type Reader struct{ ID int }
type Writer struct{ ID int }

type ReadWriter struct {
	Reader
	Writer
}

func main() {
	rw := ReadWriter{Reader{1}, Writer{2}}
	// fmt.Println(rw.ID) // compile error: ambiguous selector rw.ID
	fmt.Println(rw.Reader.ID, rw.Writer.ID)
}

Разрешите конфликт, используя полный путь, или определите ID на внешнем типе.

Встраивание интерфейсов

Интерфейсы могут встраивать другие интерфейсы. Стандартная библиотека так строит интерфейсы побольше:

type ReadWriter interface {
	Reader
	Writer
}

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

package main

import (
	"fmt"
	"io"
	"strings"
)

// countingReader wraps any io.Reader and counts bytes read.
type countingReader struct {
	io.Reader
	n int
}

func (c *countingReader) Read(p []byte) (int, error) {
	n, err := c.Reader.Read(p) // call the wrapped reader
	c.n += n
	return n, err
}

func main() {
	cr := &countingReader{Reader: strings.NewReader("hello, embedding")}
	data, err := io.ReadAll(cr)
	if err != nil {
		fmt.Println(err)
		return
	}
	fmt.Println(string(data), cr.n)
}

Явный вызов c.Reader.Read(p) обязателен. Если написать c.Read(p) внутри Read, метод будет вызывать сам себя бесконечно.

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

Частое реальное применение: встраивание sync.Mutex

type Stats struct {
	sync.Mutex
	hits map[string]int
}

func (s *Stats) Hit(page string) {
	s.Lock()
	defer s.Unlock()
	s.hits[page]++
}

Читается это хорошо, но заодно экспортирует Lock и Unlock как часть API Stats, так что любой вызывающий код может заблокировать вашу структуру. Для типов, которые используются вне пакета, именованное поле (mu sync.Mutex) оставляет блокировку приватной. Этот компромисс касается любого встраивания: всё, что экспортирует встроенный тип, становится частью публичного интерфейса вашего типа.

Частые ошибки

• Ожидание виртуальной диспетчеризации. Продвинутые методы никогда не вызывают переопределения внешнего типа.
• Задание продвинутых полей в литерале. Используйте имя встроенного типа: Admin{User: User{Name: "Ana"}}.
• nil во встроенных указателях. Встроенный *T или интерфейс нужно задать до вызова его методов.
• Случайное расширение API. Встраивание выставляет на вашем типе все экспортированные методы внутреннего типа.