I. Composite — Structural Pattern

The Composite pattern is a structural design pattern that lets you compose objects into tree structures to represent part-whole hierarchies. It allows clients to treat individual objects and groups of objects uniformly.

The key idea behind Composite is "has-a" over "is-a" — instead of inheriting from a base class, objects hold references to other objects of the same interface. This makes it natural to model recursive, tree-like structures where leaves and branches behave the same way from the outside.

Use Composite when:

• You need to represent a hierarchy of objects (e.g. file systems, UI components, org charts)

• You want to treat individual items and containers of items the same way

• You want to apply operations recursively across a tree without special-casing leaf vs. branch

II. Real-world Example

Imagine a file system with folders and files:

1. A Folder can contain multiple File items and nested Folder items

2. A File is a leaf — it has no children

3. Both Folder and File support the same operations: GetName() and Print()

4. When you call Print() on a Folder, it recursively prints all of its children, indented by depth level

5. The client code doesn't need to know whether it's dealing with a leaf or a composite — it just calls Print()

III. Implementation

component.go — the shared interface

1package composite
2
3type Component interface {
4	GetName() string
5	Print(args ...interface{})
6}

file.go — the leaf node

1package composite
2
3import (
4	"fmt"
5)
6
7type File struct {
8	name string
9}
10
11func (m *File) GetName() string {
12	return m.name
13}
14
15func (m *File) SetName(name string) {
16	m.name = name
17}
18
19func (m *File) Print(args ...interface{}) {
20	fmt.Println(m.GetName())
21}

folder.go — the composite node

1package composite
2
3import (
4	"fmt"
5	"log"
6	"strings"
7)
8
9type Folder struct {
10	name       string
11	components []Component
12}
13
14func (m *Folder) GetName() string {
15	return m.name
16}
17
18func (m *Folder) SetName(name string) {
19	m.name = name
20}
21
22func (m *Folder) Print(args ...interface{}) {
23	fmt.Println(m.name)
24	nested := 0
25	if len(args) > 0 {
26		var ok bool
27		nested, ok = args[0].(int)
28		if !ok {
29			log.Fatal("first argument must be a number")
30		}
31	}
32	for _, s := range m.components {
33		fmt.Printf("%s%s%s", strings.Repeat("  ", nested), strings.Repeat(" ", nested), "|--")
34		s.Print(nested + 1)
35	}
36}
37
38func (m *Folder) Add(c ...Component) {
39	m.components = append(m.components, c...)
40}

IV. Explain the example above

Let's trace through a concrete usage:

1root := &Folder{name: "root"}
2docs := &Folder{name: "docs"}
3src  := &Folder{name: "src"}
4
5docs.Add(&File{name: "readme.md"}, &File{name: "changelog.md"})
6src.Add(&File{name: "main.go"}, &File{name: "handler.go"})
7root.Add(docs, src, &File{name: ".gitignore"})
8
9root.Print()

Output:

1root
2|--docs
3   |--readme.md
4   |--changelog.md
5|--src
6   |--main.go
7   |--handler.go
8|--|-- .gitignore

Step by step:

1. root.Print() is called with no args → nested = 0, prints "root"

2. It iterates over its components: docs, src, .gitignore

3. For docs (a Folder): prints "|--" then calls docs.Print(1) → prints "docs", then indents its children with nested=1

4. readme.md and changelog.md are File nodes — Print() on a File simply calls fmt.Println(m.GetName()), no recursion needed

5. Same flow repeats for src, then .gitignore is printed as a flat leaf

The client code (root.Print()) never checks whether a component is a File or Folder — both satisfy the Component interface. The tree walks itself through polymorphism and recursion.

The Add() variadic signature lets you add multiple children in one call:

1docs.Add(&File{name: "readme.md"}, &File{name: "changelog.md"})
2// equivalent to two separate Add() calls

V. Conclusion

The Composite pattern shines when you need to work with hierarchical, recursive structures — file systems, UI trees, org charts, menu systems. By hiding the leaf/composite distinction behind a common interface, it makes client code clean and extensible.

However, like all patterns, it comes with trade-offs:

• Good fit: when leaves and containers behave nearly identically and you want to add new component types without touching existing code (Open/Closed Principle)

• Poor fit: when the differences between leaves and composites are significant — forcing them into the same interface adds unnecessary complexity and makes the design harder to maintain

No pattern is universally superior. Use Composite when the uniformity it provides genuinely simplifies your design.

VI. References

• Go Design Patterns — Mario Castro Contreras

• Source code on GitHub