Flyweight Pattern — Core Concepts

What the Flyweight Pattern does

The Flyweight Pattern minimizes memory usage by sharing as much data as possible between similar objects. It splits object state into two categories:

• Intrinsic state: Data that’s the same across many objects — stored once and shared
• Extrinsic state: Data that’s unique to each object — stored separately

A flyweight object holds only intrinsic state. Extrinsic state is passed in from the outside when needed.

When memory matters

Python objects carry overhead. Each instance has a __dict__ (typically 56+ bytes), a type pointer, and a reference count. For a handful of objects, this is negligible. For millions, it dominates memory usage.

Consider a text editor rendering a document with 100,000 characters. Each character has a font, size, color, and style. If every character is a full object with all that data, memory usage explodes. With flyweights, characters sharing the same formatting point to one shared formatting object.

Intrinsic vs extrinsic — how to split

Ask two questions about each piece of data:

1. Is it the same across many instances? → Intrinsic (share it)
2. Is it unique per instance? → Extrinsic (pass it in)

Example domain	Intrinsic (shared)	Extrinsic (unique)
Game trees	Texture, model, species	Position, health
Document characters	Font, color, style	Position in text
Map markers	Icon image, category	Latitude, longitude
Product catalog	Description, image URL	User’s cart quantity

The flyweight factory

A flyweight factory ensures that identical intrinsic state is stored only once. When you request a flyweight with certain properties, the factory either returns an existing one or creates a new one and caches it.

This is similar to Python’s string interning — small strings that appear frequently are stored once and shared. The sys.intern() function makes this explicit.

Python’s built-in flyweights

Python already uses flyweight-like optimization:

• Small integers (-5 to 256) are cached and reused
• String interning for identifiers
• __slots__ eliminates per-instance __dict__, saving memory per object
• tuple and frozenset are immutable, making them natural flyweight candidates

When to use it

• You have thousands or millions of similar objects
• Most of the data in each object is shared with others
• You can separate shared state from unique state cleanly
• Memory is a constraint (embedded systems, large datasets, long-running servers)

When to skip it

• You have few objects — the pattern adds complexity for no gain
• Object state is mostly unique — nothing to share
• You can solve the memory problem by changing data structures (using arrays or databases instead of objects)

Common misconception

“Flyweight is just caching.” Caching stores results to avoid recomputation. Flyweight shares object parts to avoid memory duplication. They’re related but solve different problems. A flyweight factory uses a cache internally, but the pattern is about structural sharing of object state.

The one thing to remember: Flyweight splits objects into shared (intrinsic) and unique (extrinsic) parts, so thousands of similar objects can exist without duplicating the data they have in common.