Embedding: composition instead of inheritance

A Service that embeds a Logger can call svc.Log("starting") without declaring a single method, and a Java developer reading it sees a subclass. It is not one: when a method of the Logger calls another method, it calls the Logger’s own version, even if Service declares one with the same name.

You will embed a struct and use what it promotes, predict which name a selector finds, and see why nothing is ever overridden. Under each program is the output Go 1.27.1 printed when it ran.

An embedded field lends the outer type its fields and methods

type Service struct { Logger; Name string } has two fields. Logger is an embedded fieldembedded field: A struct field declared with a type and no name, such as Audit in struct { Audit; ID string }. The type's name serves as the field's name, and its fields and methods are promoted to the outer struct.: declared with a type and no name, it is called after its type, and its fields and methods are promotedpromoted field: A field or method of an embedded field that can be used as if the outer struct declared it, such as o.CreatedBy for o.Audit.CreatedBy, unless a name at a shallower depth hides it., usable as if Service had declared them:

// service.go: a Service embeds a Logger and gains its field and its method.
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: Prefix and Log are promoted to Service
	Name   string
}

// LogWriter is any type that has a Log method.
type LogWriter interface {
	Log(msg string)
}

func main() {
	svc := &Service{Logger: Logger{Prefix: "[pay]"}, Name: "payments"}
	svc.Log("starting " + svc.Name) // promoted: svc.Logger.Log
	svc.Prefix = "[pay v2]"         // a promoted field
	svc.Logger.Log("the long way round")

	var w LogWriter = svc // *Service has Log, through its embedded Logger
	w.Log("through an interface")
	fmt.Printf("%+v\n", *svc)
}

[pay] starting payments
[pay v2] the long way round
[pay v2] through an interface
{Logger:{Prefix:[pay v2]} Name:payments}

svc.Log and svc.Prefix worked although Service declares neither, and svc.Logger.Log reached the same method by its full name. Step through how Go finds them:

Go searched by depth: first what Service declares itself, then what its embedded Logger holds, one level down. The method ran with the inner value as its receiver, &svc.Logger, so Log never saw the Service around it. A promoted method also counts when Go checks an interfaceA type that lists method signatures, such as LogWriter with Log(msg string). Any type whose methods include them can be stored in a variable of that interface type, with nothing to declare.: *Service has Log through Logger, so a *Service could be stored in a LogWriter. An embedded field can also be an interface, whose methods call the value it holds, and an interface can embed others, as io.ReadWriter embeds io.Reader and io.Writer.

The shallowest name wins, and a tie is an error only when used

When the outer type declares a name that an embedded field also has, the outer one is found first, at depth 0, and hides the other. Two embedded fields at the same depth may both have a name:

// shadow.go: the outer type's own method wins over a promoted one, and both embedded fields stay reachable.
package main

import "fmt"

type Logger struct{ Prefix string }

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

type Metrics struct{ Prefix string }

func (m Metrics) Count(name string) { fmt.Println(m.Prefix + "count " + name) }

type Service struct {
	Logger
	Metrics
}

// Log shadows Logger.Log, and still calls it by its full name.
func (s Service) Log(msg string) {
	s.Logger.Log("service: " + msg)
}

func main() {
	s := Service{Logger{"[log] "}, Metrics{"[metrics] "}}
	s.Log("ready")      // Service.Log, at depth 0
	s.Count("requests") // Metrics.Count, at depth 1
	fmt.Printf("%q %q\n", s.Logger.Prefix, s.Metrics.Prefix)
}

[log] service: ready
[metrics] count requests
"[log] " "[metrics] "

s.Log ran Service’s own Log, which called the hidden s.Logger.Log by its full name. s.Count came from Metrics. Logger and Metrics both have a Prefix, and that compiled because no line used s.Prefix; the program named each in full. Asking for the shared name is what the specification forbids:

// ambiguous.go: two embedded fields at the same depth both have a Prefix.
package main

import "fmt"

type Logger struct{ Prefix string }
type Metrics struct{ Prefix string }

type Service struct {
	Logger
	Metrics
}

func main() {
	s := Service{Logger{"[log] "}, Metrics{"[metrics] "}}
	fmt.Println(s.Prefix)
}

# command-line-arguments
./ambiguous.go:16:16: ambiguous selector s.Prefix

ambiguous selector s.Prefix: there is not exactly one Prefix at the shallowest depth, so the compiler refuses to guess. A duplicate name at one level is harmless as long as nothing asks for it by its short name.

A promoted method runs on the inner value, so nothing is overridden

Here is the surprise of the opening, as a program. Base’s Describe calls b.Name(), and Outer, which embeds Base, declares a Name of its own:

// dispatch.go: a method of an embedded type calls its own methods, never the outer type's.
package main

import "fmt"

type Base struct{}

func (Base) Name() string { return "base" }

func (b Base) Describe() string { return "I am " + b.Name() }

type Outer struct {
	Base
}

func (Outer) Name() string { return "outer" }

func main() {
	o := Outer{}
	fmt.Println(o.Name())     // Outer's own method
	fmt.Println(o.Describe()) // promoted from Base: calls Base.Name
}

outer
I am base

o.Name() returned outer, but o.Describe() printed I am base. Follow the second call:

Describe is Base’s method, compiled with a Base receiver, so the b.Name() inside it always means Base’s Name. In Java, a call like it inside a superclass reaches the subclass’s override; in Go, the FAQ says, methods on a concrete type are always resolved statically, and the only way to get dynamic dispatchdynamic dispatch: Choosing which method a call runs from the type of the value at run time, not from the type written in the code. In Go only calls through an interface are dispatched this way. is through an interface.

Code ported from a language with inheritance runs into this first:

Embedding interfaces, and the API an embedded field exposes Pro: opens with a Pro, Premium or Ultimate pass

From a class hierarchy to composition, case by case Pro: opens with a Pro, Premium or Ultimate pass

Practise

The practice questions stay with promotion, shadowing and the missing override, and come back to whichever of the three your answers show is weakest; each choice explains itself:

Interview questions

Warm-up (fresher): Is embedding in Go the same as inheritance?

No. Embedding puts a value of one type inside another and promotes its fields and methods, so the outer type can use them by their short names. But a promoted method still runs on the inner value: when it calls another method, it calls the inner type’s own version, never one the outer type declares. Only a call through an interface chooses its method by the value’s type when the program runs.

Three longer questions of the module bank build on this lesson:

Key takeaways

• An embedded field is declared by its type alone, and its fields and methods are promoted to the outer type, which can then satisfy interfaces through them.
• A selector finds the name at the shallowest depth; the outer type’s own names hide promoted ones, and two names at the same depth are an error only when used.
• A promoted method runs on the inner value and calls the inner type’s methods, so nothing is overridden; only calls through an interface are dispatched at run time.