Composite

The problem

You have a tree: files inside folders, UI elements inside containers, an org chart of managers and reports. The painful way to process it is to keep asking “is this a single thing or a group?” and branching:

func printAny(x any, indent int) {
	switch v := x.(type) {
	case *File:
		// print file
	case *Folder:
		// print folder, then loop children and recurse...
	}
}

Every operation re-implements that type switch and recursion. Composite removes both by giving leaves and containers one shared interface — so the recursion lives inside the containers, and callers just make one polymorphic call.

Structure

classDiagram
class Component {
  <<interface>>
  +Name() string
  +Print(indent)
}
class File {
  +Name() string
  +Print(indent)
}
class Folder {
  -children Component[]
  +Add(Component)
  +Name() string
  +Print(indent)
}
Component <|.. File
Component <|.. Folder
Folder o--> Component : children

The crucial line is Folder o--> Component: a container holds the same interface it implements. That self-reference is what lets folders nest folders to any depth.

How it works

One call on the root fans out through the whole tree:

graph TD
P["Folder: project"] --> M["File: go.mod"]
P --> S["Folder: src"]
S --> A["File: main.go"]
S --> B["File: util.go"]

Idiomatic Go

There’s no inheritance — just a small interface and a struct that embeds a slice of it. Edit and Run:

package main

import (
"fmt"
"strings"
)

// Component: the common interface leaves and composites both satisfy.
type Component interface {
Name() string
Print(indent int)
}

// File is a leaf — no children.
type File struct{ name string }

func (f *File) Name() string { return f.name }
func (f *File) Print(indent int) {
fmt.Printf("%sFile: %s\n", strings.Repeat("  ", indent), f.name)
}

// Folder is a composite — it holds child Components (files OR folders).
type Folder struct {
name     string
children []Component
}

func (f *Folder) Name() string   { return f.name }
func (f *Folder) Add(c Component) { f.children = append(f.children, c) }
func (f *Folder) Print(indent int) {
fmt.Printf("%sFolder: %s\n", strings.Repeat("  ", indent), f.name)
for _, c := range f.children {
	c.Print(indent + 1) // same call — leaf or folder
}
}

func main() {
root := &Folder{name: "project"}
root.Add(&File{name: "go.mod"})

src := &Folder{name: "src"}
src.Add(&File{name: "main.go"})
src.Add(&File{name: "util.go"})
root.Add(src)

root.Print(0) // one call walks the entire tree
}

Transparency vs safety

GoF frames Composite’s one real design decision as transparency vs safety — where do child-management methods (Add, Remove) live?

• Transparency: put them on the shared Component interface. Every node looks identical and clients never type-assert — but a File.Add(...) is meaningless and must panic or no-op.
• Safety: put them only on Folder. No nonsensical leaf methods — but a client that holds a Component must type-assert to *Folder before adding a child.

Go nudges firmly toward safety: keep the shared interface to what both leaf and container genuinely support (here Name/Print), and expose Add only on Folder. A small, honest interface beats a uniform-but-lying one — the same instinct behind Go’s tiny single-method interfaces.

In the standard library

• io/fs & filepath.WalkDir walk a composite file tree through the fs.FS interface.
• go/ast nodes form a composite — ast.Inspect recurses uniformly over them.
• html.Node (golang.org/x/net/html) is a composite DOM tree.

Pitfalls

When to use it — and when not

Related patterns