Embed Struct ב-Golang: הטמעה ומתודות מקודמות

הטמעה בדוגמה אחת

שדה עם טיפוס אבל בלי שם הוא שדה מוטמע. השדות והמתודות של הטיפוס המוטמע נגישים ישירות על הטיפוס החיצוני.

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.

מתודות מקודמות מממשות interfaces

קידום מוסיף את המתודות של הטיפוס המוטמע ל-method set של הטיפוס החיצוני. לכן הטיפוס החיצוני מממש כל interface שהטיפוס הפנימי מממש.

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")
}

הכללים של method sets נקבעים לפי הטיפוס המוטמע. הטמעה של T מקדמת את מתודות ה-value receiver של T גם לערך החיצוני וגם למצביע החיצוני, אבל את מתודות ה-pointer receiver של *T רק למצביע החיצוני. הטמעה של *T מקדמת את שתי הקבוצות לשניהם. אם יש ספק, הטמיעו את המצביע, או השתמשו בטיפוס החיצוני דרך מצביע.

להטמעת מצביע יש מחיר: המצביע יכול להיות nil. Service{} בלי Logger מתקמפל, ואז svc.Log(...) גורם ל-panic.

הטמעה היא לא ירושה

הטמעה נראית כמו יצירת תת מחלקה, אבל שלושה דברים מתנהגים אחרת מאשר ב-Java או ב-Python.

הטיפוס החיצוני הוא לא הטיפוס הפנימי. Admin הוא לא User. פונקציה שמקבלת User לא תקבל Admin; העבירו את a.User.

אין virtual dispatch. מתודה מקודמת רצה על הערך המוטמע, והיא לא יודעת כלום על הטיפוס החיצוני. אם היא קוראת למתודה אחרת, היא קוראת לגרסה של הטיפוס שלה, גם כשהטיפוס החיצוני מגדיר מתודה באותו שם.

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(), וה-receiver של הקריאה הזאת הוא ה-Animal. כשרוצים התנהגות שמשתנה לפי טיפוס, השתמשו ב-interface: העבירו 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 על הטיפוס החיצוני.

הטמעת interfaces

interfaces יכולים להטמיע interfaces אחרים. הספרייה הסטנדרטית בונה כך interfaces גדולים יותר:

type ReadWriter interface {
	Reader
	Writer
}

גם struct יכול להטמיע interface. ה-struct אז מממש את ה-interface הזה דרך כל ערך ששומרים בשדה, ודורסים רק את המתודות שמעניינות אתכם. זה דפוס ה-decorator כמעט בלי קוד:

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 הייתה קוראת לעצמה לנצח.

הטמעת interface ב-test fake היא קיצור דרך נפוץ: מטמיעים את ה-interface הגדול, מממשים את המתודה היחידה שהבדיקה צריכה, ומשאירים את השאר. כל מתודה שלא מומשה גורמת ל-panic עם nil pointer dereference אם קוראים לה, ולעיתים קרובות זה בדיוק מה שרוצים בבדיקה.

שימוש אמיתי נפוץ: הטמעת 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, כך שכל קורא יכול לנעול את ה-struct שלכם. בטיפוסים שמשמשים מחוץ לחבילה, שדה עם שם (mu sync.Mutex) שומר את הנעילה פרטית. השיקול הזה חל על כל הטמעה: כל מה שהטיפוס המוטמע מייצא הופך לחלק מהממשק הציבורי של הטיפוס שלכם.

טעויות נפוצות

• ציפייה ל-virtual dispatch. מתודות מקודמות אף פעם לא קוראות לדריסות של הטיפוס החיצוני.
• הצבת שדות מקודמים בליטרל. השתמשו בשם של הטיפוס המוטמע: Admin{User: User{Name: "Ana"}}.
• מצביעים מוטמעים שהם nil. צריך להציב *T או interface מוטמעים לפני שקוראים למתודות שלהם.
• חשיפת API בטעות. הטמעה מייצאת על הטיפוס שלכם את כל המתודות המיוצאות של הטיפוס הפנימי.