I. Flyweight — Structural Pattern

The Flyweight pattern is a structural design pattern that reduces memory consumption by sharing as much state as possible between similar objects. Instead of storing all data in each object, Flyweight splits state into two categories:

• Intrinsic state — data that is shared across many objects; stored once inside the flyweight object (e.g. tree species, color, texture)

• Extrinsic state — data that is unique to each object instance; passed in by the caller at runtime (e.g. x, y position on the map)

The flyweight object itself is immutable and reusable. A factory (or cache) ensures that only one flyweight instance exists per unique combination of intrinsic state.

Use Flyweight when:

• You need to create a very large number of similar objects and memory is a concern

• Most of the object's state can be made extrinsic (moved outside the object)

• Many groups of objects share the same intrinsic data

II. Real-world Example

A forest rendering system with thousands of trees:

1. A forest can have thousands of Tree objects, but trees of the same species share identical data: name, color, texture

2. Without Flyweight: 1,000 trees × 3 fields = 3,000 strings in memory

3. With Flyweight: only 2–3 TreeType objects exist, regardless of how many trees there are

4. Each Tree stores only its position (x, y) and a pointer to the shared TreeType

5. GetTreeType() acts as the factory: returns an existing TreeType from cache, or creates a new one

III. Implementation

tree_type.go — the flyweight (intrinsic state)

1package flyweight
2
3import "fmt"
4
5// TreeType holds intrinsic (shared) state — species, color, texture.
6// Many Tree instances can share a single TreeType.
7type TreeType struct {
8	Name    string
9	Color   string
10	Texture string
11}
12
13func (t *TreeType) Render(x, y int) {
14	fmt.Printf("Rendering tree [%s | color:%s | texture:%s] at (%d, %d)\n",
15		t.Name, t.Color, t.Texture, x, y)
16}

tree.go — the context (extrinsic state)

1package flyweight
2
3// Tree holds extrinsic (context-specific) state — position on the map.
4// It delegates rendering to the shared TreeType flyweight.
5type Tree struct {
6	X        int
7	Y        int
8	TreeType *TreeType
9}
10
11func (t *Tree) Render() {
12	t.TreeType.Render(t.X, t.Y)
13}

tree_factory.go — the flyweight factory/cache

1package flyweight
2
3import "fmt"
4
5var treeTypes = map[string]*TreeType{}
6
7// GetTreeType returns a cached TreeType or creates a new one if not found.
8// This is the core of the Flyweight pattern — reuse shared instances.
9func GetTreeType(name, color, texture string) *TreeType {
10	key := fmt.Sprintf("%s-%s-%s", name, color, texture)
11	if tt, ok := treeTypes[key]; ok {
12		return tt
13	}
14	tt := &TreeType{Name: name, Color: color, Texture: texture}
15	treeTypes[key] = tt
16	fmt.Printf("Created new TreeType: %s\n", key)
17	return tt
18}
19
20func TreeTypeCount() int {
21	return len(treeTypes)
22}

forest.go — the client

1package flyweight
2
3// Forest manages a large collection of Tree objects.
4// Despite having thousands of trees, only a handful of TreeType objects exist.
5type Forest struct {
6	trees []*Tree
7}
8
9func (f *Forest) PlantTree(x, y int, name, color, texture string) {
10	tt := GetTreeType(name, color, texture)
11	f.trees = append(f.trees, &Tree{X: x, Y: y, TreeType: tt})
12}
13
14func (f *Forest) Render() {
15	for _, t := range f.trees {
16		t.Render()
17	}
18}
19
20func (f *Forest) Count() int {
21	return len(f.trees)
22}

IV. Explain the example above

Let's trace through planting 1,000 trees of 2 types:

1f := &Forest{}
2
3for i := 0; i < 500; i++ {
4	f.PlantTree(i, i*2, "Oak", "dark-green", "rough")
5}
6for i := 0; i < 500; i++ {
7	f.PlantTree(i, i*3, "Pine", "light-green", "smooth")
8}
9
10fmt.Println("Trees:", f.Count())         // 1000
11fmt.Println("TreeTypes:", TreeTypeCount()) // 2
12
13f.Render()

Output (first few lines):

1Created new TreeType: Oak-dark-green-rough
2Created new TreeType: Pine-light-green-smooth
3Rendering tree [Oak | color:dark-green | texture:rough] at (0, 0)
4Rendering tree [Oak | color:dark-green | texture:rough] at (1, 2)
5Rendering tree [Oak | color:dark-green | texture:rough] at (2, 4)
6...
7Rendering tree [Pine | color:light-green | texture:smooth] at (0, 0)
8...

Step by step:

1. First call PlantTree(0, 0, "Oak", "dark-green", "rough") — key "Oak-dark-green-rough" not in cache → creates new TreeType, stores it, logs "Created new TreeType"

2. Second call PlantTree(1, 2, "Oak", "dark-green", "rough") — same key, cache hit → returns existing TreeType pointer. No new object created.

3. This repeats for all 500 Oak trees — only 1 TreeType object ever exists for Oak

4. First Pine call creates a second TreeType; all 500 Pine trees share it

5. TreeTypeCount() == 2 while f.Count() == 1000

6. f.Render() iterates all 1,000 Tree objects, each calling t.TreeType.Render(t.X, t.Y) — the position (extrinsic) is passed at call time, not stored in TreeType

The memory saving: instead of 1,000 × 3 strings, you have 2 × 3 strings + 1,000 × (2 ints + 1 pointer). As tree count grows, the TreeType pool stays constant.

V. Conclusion

The Flyweight pattern is a memory optimization first and foremost. It trades a small amount of design complexity (separating intrinsic/extrinsic state) for significant memory savings at scale.

Trade-offs:

• Good fit: rendering systems (game engines, map tiles, text glyphs, particle systems); any scenario with large numbers of nearly-identical objects where memory is constrained

• Poor fit: when objects don't actually share much state, or when the overhead of the factory cache and separating state adds complexity without meaningful savings; also adds thread-safety concerns if the cache is global and mutated concurrently

One thing to watch: the global treeTypes map in this implementation is not thread-safe. In concurrent scenarios, you'd want a mutex around reads and writes to the cache.

No pattern is universally superior. Use Flyweight when you can measure a real memory problem, not just as a premature optimization.

VI. References

• Go Design Patterns — Mario Castro Contreras

• Source code on GitHub