Intrinsic vs. Extrinsic State in the Flyweight Pattern

Intrinsic state: The part of a flyweight that can be shared safely across uses.

Extrinsic state: The context the caller supplies for each use because it should not be stored in the shared object.

This distinction is the center of the Flyweight pattern. If the boundary is wrong, the pattern collapses.

    flowchart LR
	    A["Client"] --> B["Supplies extrinsic state"]
	    B --> C["Flyweight"]
	    C --> D["Intrinsic state kept inside"]
	    B --> E["Position, request context, owner, or timestamp kept outside"]

Intrinsic State

Intrinsic state should be:

• immutable
• small enough to share comfortably
• identical across many logical uses

Examples:

• glyph style
• sprite definition
• product catalog snapshot data
• parsed schema metadata

Extrinsic State

Extrinsic state usually depends on one use site:

• screen position
• current user
• quantity
• invocation time
• request-specific flags

If that state is stored inside the shared flyweight, the flyweight stops being safely reusable.

Design Review Rule

When deciding whether something is intrinsic, ask:

• would two callers be correct using the same value simultaneously?

If the answer is no, the state is probably extrinsic.