Flyweight

Intuition

Imagine a big game map or document:

• Thousands of visual elements on screen.

• Many of them share the same look or configuration.

If every element stored its own copy of all style or visual data, memory usage would explode. Instead, you can:

• Store the shared visual/style data once and reuse it.

• For each element, store only what is unique, like position or small per‑instance attributes.

The Flyweight Design Pattern does exactly this: it shares common, immutable state across many objects and keeps unique state outside, supplied when needed.

Core idea: intrinsic vs extrinsic state

Flyweight is about splitting object state into two parts:

• Intrinsic state

  • Shared, invariant data.

  • Stored inside the flyweight object.

  • Example: tree type, texture, and color; or font, size, and color for text.

• Extrinsic state

  • Per‑instance, changing data.

  • Not stored in the flyweight; passed in from the outside whenever you use it.

  • Example: tree position (x, y) or a character’s coordinates in a document.

A Flyweight Factory manages a pool (cache) of flyweight objects so that identical intrinsic states reuse the same underlying object instead of creating duplicates.

Goal:

Support a huge number of fine‑grained objects while keeping memory low by sharing common parts.

C++ example: Forest with many trees

Suppose you’re drawing a forest with tens of thousands of trees in a game.

Step 1: Flyweight for shared tree type

TreeType Holds the intrinsic state: name, color, texture.
Thousands of trees can share the same. TreeType.

Step 2: Flyweight factory (sharing instances)

The factory ensures that for each unique combination of intrinsic state, there is only one TreeType instance.

Step 3: Tree objects with extrinsic state

Each Tree stores only its unique position and a pointer to a shared TreeType.

Step 4: Using many trees

Even with 20,000 trees, you only have a handful of TreeType objects in memory, plus light Tree objects containing coordinates and a pointer. That is the memory saving that Flyweight targets.

When Flyweight is useful

Flyweight shines when:

• You have a very large number of similar objects (characters, tiles, particles, nodes).

• Many of those objects share the same configuration or appearance.

• Memory usage is a real concern.

• You can clearly separate shared vs per‑instance state.

Typical domains:

• Text editors: shared style vs per‑character position.

• Game maps: tile types vs tile coordinates.

• GUI icons: the same image in many places with different positions.

• Large graphs or networks with repeated node types.

Trade‑offs and responsibilities

Benefits:

• Large reduction in memory usage by sharing intrinsic state.

• Can improve performance when memory is the main bottleneck.

Costs:

• Design is more complex than “each object stores everything.”

• Clients must manage and provide the extrinsic state at use time.

• Flyweight objects are best kept immutable so sharing them is safe.

If you cannot clearly separate what should be shared and what should be unique, Flyweight may not be appropriate.

Relation to other patterns

• Flyweight vs Singleton

  • Singleton ensures only one global instance of a class.

  • Flyweight allows many shared instances, one per unique intrinsic state (typically managed by a factory).

• Flyweight vs Prototype

  • Prototype clones fully configured objects.

  • Flyweight shares common parts and keeps unique data outside the flyweight.

• Flyweight vs Object Pool

  • Object pool reuses objects over time to avoid frequent allocations.

  • FA flyweight shares immutable state among many logical objects at the same time.