Flyweight in Go

The Problem

Large collections often repeat the same immutable data many times. A cart, a catalog index, or an inventory snapshot might contain thousands of references to the same SKU metadata. If every item owns a full copy, memory usage grows with needless duplication.

The Solution

Flyweight extracts the shared intrinsic state into a reusable object and keeps changing extrinsic state outside of it. In Go, a cache or factory typically owns the shared flyweights, while callers keep their per-instance quantities, locations, or timestamps separately.

Structure

flowchart LR
Client["Client"]
Factory["MetadataFactory"]
Cache["internal cache"]
Flyweight["ProductMetadata
shared immutable"]
Context["CartLine
per-instance state"]

Client -->|"Get(sku)"| Factory
Factory -->|"checks"| Cache
Cache -->|"returns cached"| Flyweight
Factory -->|"creates if missing"| Flyweight
Client -->|"stores in"| Context
Context -->|"references"| Flyweight

• Flyweight: ProductMetadata holds shared immutable SKU data.
• Flyweight factory: MetadataFactory returns cached flyweights by SKU.
• Context object: CartLine keeps changing per-line values such as quantity and warehouse.
• Client: Reuses the same flyweight across multiple contexts.

Implementation

This example shares catalog metadata for repeated SKUs across multiple cart lines. Each line keeps its own quantity and warehouse, while the expensive descriptive fields are reused through a factory-managed cache.

package main

type ProductMetadata struct {
	SKU      string
	Name     string
	Category string
}

package main

type MetadataFactory struct {
	cache map[string]*ProductMetadata
}

func NewMetadataFactory() *MetadataFactory {
	return &MetadataFactory{cache: make(map[string]*ProductMetadata)}
}

func (f *MetadataFactory) Get(sku string, name string, category string) *ProductMetadata {
	if metadata, ok := f.cache[sku]; ok {
		return metadata
	}
	metadata := &ProductMetadata{SKU: sku, Name: name, Category: category}
	f.cache[sku] = metadata
	return metadata
}

package main

import "fmt"

type CartLine struct {
	Metadata  *ProductMetadata
	Quantity  int
	Warehouse string
}

func (l CartLine) Summary() string {
	return fmt.Sprintf("%s x%d from %s", l.Metadata.Name, l.Quantity, l.Warehouse)
}

package main

import "fmt"

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

	factory := NewMetadataFactory()
	meta1 := factory.Get("KB-001", "Mechanical Keyboard", "peripherals")
	meta2 := factory.Get("KB-001", "Mechanical Keyboard", "peripherals")

	lineA := CartLine{Metadata: meta1, Quantity: 1, Warehouse: "PPH-A"}
	lineB := CartLine{Metadata: meta2, Quantity: 3, Warehouse: "PPH-B"}

	fmt.Println(lineA.Summary())
	fmt.Println(lineB.Summary())
	fmt.Printf("shared metadata: %t\n", meta1 == meta2)
}

Real-World Analogy

Think of a library catalog. Thousands of checkout records may point to the same book metadata record instead of copying the full title, author, and publisher data into every transaction.

Pros and Cons

Best Practices

• Keep flyweights immutable or treat them as effectively read-only once cached.
• Separate intrinsic shared state from extrinsic per-instance state clearly.
• Measure first. Flyweight is a performance pattern and only matters when repetition is actually large enough.
• Hide caching behind a factory so callers do not manage reuse manually.
• Avoid Flyweight if shared state becomes difficult to reason about or accidentally mutable.

When to Use

• You have many objects that repeat the same immutable data.
• Memory pressure or cache efficiency matters.
• Shared metadata can be safely reused across many contexts.

When NOT to Use

• The objects are few enough that duplication is irrelevant.
• The supposedly shared state changes frequently.
• The performance optimization would complicate otherwise clear code.