{"id":1084,"date":"2026-08-17T00:32:02","date_gmt":"2026-08-17T00:32:02","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/?p=1084"},"modified":"2026-08-17T00:32:03","modified_gmt":"2026-08-17T00:32:03","slug":"go-tutorials-composition-instead-of-classical-inheritance","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/go-tutorials-composition-instead-of-classical-inheritance\/","title":{"rendered":"Go Tutorials: Composition Instead of Classical Inheritance"},"content":{"rendered":"\n

This is one of the most important mindset changes when coming to Go from Java, C++, C#, or Python.<\/p>\n\n\n\n

The key idea is simple:<\/p>\n\n\n\n

\n

Inheritance says:<\/strong> \u201cI am a type of something.\u201d
Composition says:<\/strong> \u201cI contain something and use its functionality.\u201d<\/p>\n<\/blockquote>\n\n\n\n

Go deliberately does not<\/strong> have classical inheritance such as:<\/p>\n\n\n\n

class Dog extends Animal<\/code><\/pre>\n\n\n\n
Instead, Go encourages you to build larger types by combining smaller types.<\/p>\n\n\n\n
\n\n\n\n
1. What is composition?<\/h2>\n\n\n\n
Suppose we have a Car<\/code>.<\/p>\n\n\n\n
A car needs an engine.<\/p>\n\n\n\n
In an inheritance-heavy design, you might be tempted to think about parent and child classes.<\/p>\n\n\n\n
With composition, you simply say:<\/p>\n\n\n\n
Car HAS an Engine<\/code><\/pre>\n\n\n\n
Instead of:<\/p>\n\n\n\n
Car IS an Engine<\/code><\/pre>\n\n\n\n
That distinction is the heart of composition.<\/p>\n\n\n\n
flowchart LR\n    Car[Car] -->|has an| Engine[Engine]\n    Engine --> Start[\"Start()\"]\n    Car --> Drive[\"Drive()\"]<\/code><\/pre>\n\n\n\n
\n\n\n\n
2. Complete Go Example<\/h1>\n\n\n\n
Copy-paste this entire program into main.go<\/code>.<\/p>\n\n\n\n
package main\n\nimport \"fmt\"\n\n\/\/ Engine is a small independent type.\n\/\/ It knows how to start itself.\ntype Engine struct {\n\tHorsePower int\n}\n\n\/\/ Start belongs to Engine.\nfunc (e Engine) Start() {\n\tfmt.Println(\"Engine started\")\n}\n\n\/\/ Car is made by COMPOSING smaller things together.\n\/\/\n\/\/ A Car HAS an Engine.\n\/\/ Car does not inherit from Engine.\ntype Car struct {\n\tBrand  string\n\tEngine Engine\n}\n\n\/\/ Drive belongs to Car.\n\/\/\n\/\/ Car can use the behavior of the Engine\n\/\/ because Car contains an Engine.\nfunc (c Car) Drive() {\n\tc.Engine.Start()\n\n\tfmt.Printf(\n\t\t\"%s is driving with %d HP\\n\",\n\t\tc.Brand,\n\t\tc.Engine.HorsePower,\n\t)\n}\n\nfunc main() {\n\t\/\/ Create an Engine.\n\tengine := Engine{\n\t\tHorsePower: 150,\n\t}\n\n\t\/\/ Put the Engine inside the Car.\n\tcar := Car{\n\t\tBrand:  \"Toyota\",\n\t\tEngine: engine,\n\t}\n\n\t\/\/ Car uses its composed Engine internally.\n\tcar.Drive()\n}<\/code><\/pre>\n\n\n\n
Output<\/h3>\n\n\n\n
Engine started\nToyota is driving with 150 HP<\/code><\/pre>\n\n\n\n
\n\n\n\n
3. What exactly happened?<\/h1>\n\n\n\n
Start with this:<\/p>\n\n\n\n
type Engine struct {\n\tHorsePower int\n}<\/code><\/pre>\n\n\n\n
Engine<\/code> is an independent type.<\/p>\n\n\n\n
It has its own behavior:<\/p>\n\n\n\n
func (e Engine) Start() {\n\tfmt.Println(\"Engine started\")\n}<\/code><\/pre>\n\n\n\n
Then we create another type:<\/p>\n\n\n\n
type Car struct {\n\tBrand  string\n\tEngine Engine\n}<\/code><\/pre>\n\n\n\n
This line is the important part:<\/p>\n\n\n\n
Engine Engine<\/code><\/pre>\n\n\n\n
It means:<\/p>\n\n\n\n
\n
A Car<\/code> contains an Engine<\/code>.<\/p>\n<\/blockquote>\n\n\n\n
That is composition<\/strong>.<\/p>\n\n\n\n
Conceptually:<\/p>\n\n\n\n
Car\n\u251c\u2500\u2500 Brand\n\u2514\u2500\u2500 Engine\n    \u2514\u2500\u2500 HorsePower<\/code><\/pre>\n\n\n\n
The Car<\/code> can therefore use its engine:<\/p>\n\n\n\n
c.Engine.Start()<\/code><\/pre>\n\n\n\n
and access its data:<\/p>\n\n\n\n
c.Engine.HorsePower<\/code><\/pre>\n\n\n\n
\n\n\n\n
4. Why does Go prefer composition?<\/h1>\n\n\n\n
Because large inheritance hierarchies can become tightly coupled.<\/p>\n\n\n\n
Imagine something like:<\/p>\n\n\n\n
Vehicle\n   \u2193\nCar\n   \u2193\nElectricCar\n   \u2193\nAutonomousElectricCar\n   \u2193\nDeliveryAutonomousElectricCar<\/code><\/pre>\n\n\n\n
Changes in a parent class can affect many child classes.<\/p>\n\n\n\n
Composition usually creates smaller independent pieces:<\/p>\n\n\n\n
flowchart TD\n    Car --> Engine\n    Car --> GPS\n    Car --> Battery\n    Car --> Brakes<\/code><\/pre>\n\n\n\n
A Car<\/code> becomes a combination of components.<\/p>\n\n\n\n
Car\n\u251c\u2500\u2500 Engine\n\u251c\u2500\u2500 GPS\n\u251c\u2500\u2500 Battery\n\u2514\u2500\u2500 Brakes<\/code><\/pre>\n\n\n\n
That is generally easier to understand and change.<\/p>\n\n\n\n
\n\n\n\n
5. Classical Inheritance vs Go Composition<\/h1>\n\n\n\n
Classical Inheritance<\/th>Go Composition<\/th><\/tr><\/thead>
Child extends parent<\/td>Struct contains another type<\/td><\/tr>
Dog extends Animal<\/code><\/td>Dog<\/code> contains useful components<\/td><\/tr>
Usually represents is-a<\/strong><\/td>Usually represents has-a<\/strong><\/td><\/tr>
Behavior inherited from parent<\/td>Behavior is used through contained types<\/td><\/tr>
Can create deep class hierarchies<\/td>Usually creates small independent components<\/td><\/tr>
Parent and child can become tightly coupled<\/td>Components are easier to replace<\/td><\/tr>
Common in Java\/C++\/C#<\/td>Preferred approach in Go<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
The easiest memory trick is:<\/p>\n\n\n\n
Relationship<\/th>Think<\/th><\/tr><\/thead>
Inheritance<\/td>IS-A<\/strong><\/td><\/tr>
Composition<\/td>HAS-A<\/strong><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
For our example:<\/p>\n\n\n\n
Car HAS-A Engine<\/code><\/pre>\n\n\n\n
So composition is natural.<\/p>\n\n\n\n
\n\n\n\n
6. How do I recognize composition in Go?<\/h1>\n\n\n\n
Look for one struct containing another type.<\/p>\n\n\n\n
type Engine struct {\n\tHorsePower int\n}\n\ntype Car struct {\n\tEngine Engine\n}<\/code><\/pre>\n\n\n\n
Read it naturally:<\/p>\n\n\n\n
\n
Car<\/code> has an Engine<\/code>.<\/p>\n<\/blockquote>\n\n\n\n
Then you usually access it like:<\/p>\n\n\n\n
car.Engine.Start()<\/code><\/pre>\n\n\n\n
This explicit style is very common and very easy to understand.<\/p>\n\n\n\n
\n\n\n\n
7. Where should I use composition?<\/h1>\n\n\n\n
Use composition when one thing uses, contains, owns, or depends on<\/strong> another thing.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
Car        HAS Engine\nComputer   HAS CPU\nOrder      HAS Customer\nServer     HAS Logger\nUser       HAS Address\nGame       HAS Player\nApp        HAS Database<\/code><\/pre>\n\n\n\n
These naturally become structs containing other structs.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
type Address struct {\n\tCity string\n}\n\ntype User struct {\n\tName    string\n\tAddress Address\n}<\/code><\/pre>\n\n\n\n
That is composition too.<\/p>\n\n\n\n
\n\n\n\n
8. When should I use it?<\/h1>\n\n\n\n
Whenever you find yourself thinking:<\/p>\n\n\n\n
\n
“This struct needs functionality\/data provided by another thing.”<\/p>\n<\/blockquote>\n\n\n\n
For example:<\/p>\n\n\n\n
type Server struct {\n\tLogger Logger\n}<\/code><\/pre>\n\n\n\n
Then:<\/p>\n\n\n\n
server.Logger.Log()<\/code><\/pre>\n\n\n\n
Rather than creating strange inheritance relationships.<\/p>\n\n\n\n
\n\n\n\n
9. The important mindset<\/h1>\n\n\n\n
If you come from Java, you might initially think:<\/p>\n\n\n\n
What should my parent class be?<\/code><\/pre>\n\n\n\n
In Go, try changing the question to:<\/p>\n\n\n\n
What small pieces does my type need?<\/code><\/pre>\n\n\n\n
Then combine those pieces.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
Instead of:\n\nAnimal\n  \u2193\nDog\n\nThink:\n\nDog\n\u251c\u2500\u2500 Name\n\u251c\u2500\u2500 Legs\n\u2514\u2500\u2500 Behavior<\/code><\/pre>\n\n\n\n
Go encourages building programs from small cooperating types<\/strong>, rather than large inheritance trees.<\/p>\n\n\n\n
\n\n\n\n
10. Don’t confuse composition with copying<\/h1>\n\n\n\n
When we write:<\/p>\n\n\n\n
type Car struct {\n\tEngine Engine\n}<\/code><\/pre>\n\n\n\n
we are not copying the Engine<\/code> code into Car<\/code>.<\/p>\n\n\n\n
We are saying:<\/p>\n\n\n\n
Car owns\/contains an Engine value.<\/code><\/pre>\n\n\n\n
So:<\/p>\n\n\n\n
car.Engine.Start()<\/code><\/pre>\n\n\n\n
means:<\/p>\n\n\n\n
Car\n \u2193\nEngine\n \u2193\nStart()<\/code><\/pre>\n\n\n\n
\n\n\n\n
11. One-line definition to remember<\/h1>\n\n\n\n
\n
Composition in Go means building a type by combining other types instead of inheriting from a parent class.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
The basic pattern is simply:<\/p>\n\n\n\n
type SmallThing struct {\n}\n\ntype BiggerThing struct {\n\tSmall SmallThing\n}<\/code><\/pre>\n\n\n\n
Read it as:<\/p>\n\n\n\n
BiggerThing HAS-A SmallThing<\/code><\/pre>\n\n\n\n
\n\n\n\n
Final mental model<\/h2>\n\n\n\n
flowchart LR\n    A[\"Classical OOP\"] --> B[\"Parent\"]\n    B --> C[\"Child inherits behavior\"]\n\n    D[\"Go\"] --> E[\"Small Type A\"]\n    D --> F[\"Small Type B\"]\n    E --> G[\"Composed Type\"]\n    F --> G<\/code><\/pre>\n\n\n\n
When writing Go, prefer thinking:<\/p>\n\n\n\n
Build with pieces<\/code><\/pre>\n\n\n\n
rather than:<\/p>\n\n\n\n
Build with parent\/child classes<\/code><\/pre>\n\n\n\n
So for this example:<\/p>\n\n\n\n
type Car struct {\n\tEngine Engine\n}<\/code><\/pre>\n\n\n\n
is the core idea.<\/p>\n\n\n\n
Car has an Engine \u2192 composition.<\/strong><\/p>\n\n\n\n
Not:<\/p>\n\n\n\n
Car extends Engine \u2192 inheritance.<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"
This is one of the most important mindset changes when coming to Go from Java, C++, C#, or Python. The key idea is simple: Inheritance says: \u201cI… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1084","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1084","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=1084"}],"version-history":[{"count":1,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1084\/revisions"}],"predecessor-version":[{"id":1085,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1084\/revisions\/1085"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=1084"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=1084"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=1084"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}