Composition vs Inheritance

Go favors composition—building types from fields, embedded types and small interfaces—over class-style inheritance.

With composition, a larger type can contain a reusable component and delegate work to it. Embedding can promote selectors, but it does not create a subtype relationship or provide virtual inheritance.

Interfaces supply substitutability by behavior: unrelated types can satisfy the same interface. This combination of composition and implicit interface implementation provides flexible designs without an extends keyword.

Follow this diagram before executing the example. Check where a value or decision changes what runs next.

This example is a complete program. Save it as main.go or paste it into the Go Playground.

Go code

package main

import "fmt"

type Engine struct{ Power int }

func (e Engine) Start() string { return "Engine started" }

type Car struct {
	Engine
	Model string
}

func main() {
	car := Car{Engine: Engine{Power: 120}, Model: "City"}
	fmt.Println(car.Model)
	fmt.Println(car.Start())
	fmt.Println("Power:", car.Engine.Power)
}

Output

City
Engine started
Power: 120

Car contains an embedded Engine value. Engine.Start is promoted, so car.Start() works, while car.Engine.Power still explicitly locates Power in the embedded component.

• Embedding does not make Car inherit all type identity from Engine.
• Prefer small reusable components instead of creating deep chains of embedding.

Add a Radio component with an On method and embed it in Car. Demonstrate both promoted methods.

Tip: Edit the example above, predict the output, and run the modified code to test your reasoning.

You have practiced Composition vs Inheritance in a small, self-contained program. The important habit is to predict what runs, inspect the actual output and distinguish the language rule from the particular example.

Before continuing, make sure you can explain the program to someone who has not seen it, including the line that changes its result.