This lesson follows Facade. Flyweight is a memory optimization for many similar objects.

Flyweight shares state that many logical objects repeat. It keeps each object's distinct state outside the shared object. The cost is a split representation, lookup work, and stricter immutability.

Measure repeated state

A map contains 10000 markers with two icon styles. Positions differ. Icon image data does not. If each marker independently copies 64 kibibytes of image data, the repeated image data alone uses 625 mebibytes.

Separate intrinsic and extrinsic state

State	In the marker	Owner
Intrinsic: repeated and stable	icon data and color	shared IconStyle
Extrinsic: context-specific	x, y, selected status	individual marker context

type Kind = "station" | "cafe";
class IconStyle {
  constructor(private readonly kind: Kind) {}
  draw(x: number, y: number) {
    console.log(this.kind, "at", x, y);
  }
}
class IconFactory {
  private pool = new Map<Kind, IconStyle>();
  get(kind: Kind): IconStyle {
    let style = this.pool.get(kind);
    if (!style) {
      style = new IconStyle(kind);
      Object.freeze(style);
      this.pool.set(kind, style);
    }
    return style;
  }
}
type Marker = { x: number; y: number; style: IconStyle };
const icons = new IconFactory();
const markers: Marker[] = [
  { x: 10, y: 20, style: icons.get("station") },
  { x: 50, y: 80, style: icons.get("station") },
];
for (const marker of markers) marker.style.draw(marker.x, marker.y);

The sample prints instead of loading an image. Both markers reference one IconStyle, but draw receives each marker's position. The factory creates one shared object per intrinsic key. Logical marker count stays 10000. Their contexts become smaller.

Keep the pool bounded by real reuse

Map the roles

Flyweight is only an optimization. Before applying it, confirm that many similar objects in memory at once really are the problem, and that no simpler fix exists.

Role	In this example	Job
Flyweight	IconStyle	Holds the intrinsic state that many objects share. One flyweight serves many contexts. Its methods receive the extrinsic state as arguments.
Context	Marker	Holds the extrinsic state that is unique to each object, plus a reference to its flyweight. Together they represent the full original object.
Client	the map renderer	Computes or stores each object's extrinsic state and passes it into flyweight methods
Flyweight factory	IconFactory	Manages the pool of existing flyweights. Clients pass it intrinsic state, and it returns a matching flyweight or creates a new one.

Reach for it when memory, not code shape, is the problem

Use Flyweight only when a program must support a huge number of objects that barely fit in available memory. It pays off most when all three are true:

• the application creates a huge number of similar objects
• those objects use up most of the memory on the target device
• the objects contain duplicated state that can be extracted and shared

Implement it in five steps

Refactor existing code toward the pattern in this order:

1. Split the fields of the class into intrinsic state (unchanging data duplicated across many objects) and extrinsic state (contextual data unique to each object).
2. Keep the intrinsic fields in the class and make them immutable. They get their values only in the constructor.
3. Find every method that uses an extrinsic field. For each such field, add a method parameter and use it instead of the field.
4. Optionally, create a factory class that manages a pool of flyweights and checks for an existing one before creating another. Clients then request flyweights only from the factory, describing the intrinsic state they want.
5. Make the client store or compute the extrinsic state, because it needs that state to call flyweight methods. For convenience, move the extrinsic state and the flyweight reference into a separate context class.

Name what it costs

You gain	You pay
Large memory savings when a program has many similar objects	You may trade memory for CPU when context data is recomputed on every flyweight call
One immutable representation per repeated state	The code gets more complicated. New team members will ask why an object's state is split.
Lower memory pressure	A pool keyed on the wrong state can grow without bound

Do not confuse it with its neighbors

Pattern	How it relates
Composite	Implement a composite tree's shared leaf nodes as flyweights to save memory.
Facade	Flyweight shows how to make lots of small objects. Facade shows how to make one object that represents a whole subsystem.
Singleton	If all shared state fit in one flyweight, it would resemble a singleton. There would still be two differences: a flyweight class can have many instances with different intrinsic state, and flyweights are immutable while a singleton can change.

Retrieve and apply

Estimate the repeated bytes in one real collection before proposing a pool. Continue to Proxy for a stand-in that controls access to an object.