Composite in Go

The Problem

Tree-shaped data appears everywhere: category hierarchies, organization charts, nested menu structures, and bundle catalogs. Without a common contract, callers need different code paths for leaves and groups, which makes traversal and aggregation noisy.

The Solution

Composite gives both leaves and containers a shared interface. In Go, that often means a small behavior contract plus one composite type that recursively stores children. The caller can then calculate totals or render structure without caring whether it is visiting one node or a whole branch.

Structure

flowchart TD
Client["Client"]
Node["CatalogNode
interface"]
ProductLeaf["Product
leaf"]
Category["Category
composite"]

Client -->|"traverses"| Node
ProductLeaf -.->|"implements"| Node
Category -.->|"implements"| Node
Category -->|"contains children"| Node

• Component interface: CatalogNode defines the behavior common to leaves and groups.
• Leaf: Product has no children and returns its own price.
• Composite: Category stores child nodes and aggregates over them.
• Client: Traverses the tree through the shared interface.

Implementation

This example models a nested catalog where categories can contain products or subcategories. The same interface supports recursive rendering and total price aggregation for the entire tree.

package main

import "strings"

type CatalogNode interface {
	Price() int
	Render(level int) string
}

func pad(level int) string {
	return strings.Repeat("  ", level)
}

package main

import "fmt"

type Product struct {
	Name  string
	Cents int
}

func (p Product) Price() int {
	return p.Cents
}

func (p Product) Render(level int) string {
	return fmt.Sprintf("%s- %s (%d)\n", pad(level), p.Name, p.Cents)
}

package main

import "fmt"

type Category struct {
	Name     string
	Children []CatalogNode
}

func (c Category) Price() int {
	total := 0
	for _, child := range c.Children {
		total += child.Price()
	}
	return total
}

func (c Category) Render(level int) string {
	output := fmt.Sprintf("%s+ %s\n", pad(level), c.Name)
	for _, child := range c.Children {
		output += child.Render(level + 1)
	}
	return output
}

package main

import "fmt"

func main() {
	fmt.Println("=== Composite in Go ===")

	catalog := Category{
		Name: "Workstation Bundle",
		Children: []CatalogNode{
			Product{Name: "Laptop", Cents: 140000},
			Category{
				Name: "Accessories",
				Children: []CatalogNode{
					Product{Name: "Dock", Cents: 18000},
					Product{Name: "Monitor", Cents: 32000},
				},
			},
		},
	}

	fmt.Print(catalog.Render(0))
	fmt.Printf("total cents: %d\n", catalog.Price())
}

Real-World Analogy

Think of files and folders in a filesystem. A file is a single item, a folder contains many items, but both can appear in the same tree and both can be listed, moved, or counted through a common interface.

Pros and Cons

Best Practices

• Keep the component interface small so both leaves and composites can implement it naturally.
• Let the composite own recursion. Clients should not need special cases for children.
• Avoid stuffing child-management methods into the shared interface unless leaves can handle them sensibly.
• Use Composite for real tree structures, not just any list of items.
• If traversal logic grows complex, pair Composite with Iterator or Visitor instead of bloating the node interface.

When to Use

• You work with tree-shaped data and want uniform treatment of leaves and branches.
• Aggregation or rendering should work recursively across nested groups.
• Callers should not need explicit leaf-versus-composite branching.

When NOT to Use

• The data is not naturally hierarchical.
• A flat slice and helper functions would be simpler.
• The shared interface would force unnatural methods onto leaves.