Flyweight Pattern
Flyweight: start from the problem
See the responsibilities
A document contains thousands of glyphs that share the same font style. Copying the style for every glyph repeats immutable data, while sharing each glyph’s editable position would be incorrect.
This is a structural pattern lesson. Follow the responsibilities, inspect the small JavaScript example and compare the design choices. The example is local teaching code; its boundary is explained before you apply the idea to a real service.
What you’ll learn
- Explain the problem Flyweight addresses and the roles involved.
- Follow the example and distinguish this pattern from nearby alternatives.
- Choose when the benefit justifies the extra responsibilities and testing.
How the responsibilities work
Flyweight shares reusable intrinsic state and leaves context-specific extrinsic state with the caller or owning object. Intrinsic means the safe common part; extrinsic means the values that vary for each use.
In our example, the style object is shared and immutable. Each glyph keeps its own character and position. The distinction is about ownership and meaning, not a rule that every field should be shared.
Follow a small example
Read the JavaScript from top to bottom and compare the expected output. The values are chosen to make this pattern’s responsibility visible. This example runs in one local execution context; it does not create remote services, durable storage or production access controls.
JavaScript · local teaching example
const style = Object.freeze({font: 'mono', size: 14});
const first = {character: 'A', x: 0, style};
const second = {character: 'B', x: 10, style};
console.log(first.style === second.style);
console.log(first.x + ' | ' + second.x);Expected output
true
0 | 10Choose a design and inspect the consequence
Compare the design choices
Compare the visible consequences. With JavaScript enabled, choose an option in each scenario to assemble your decision record.
This is an exploratory design exercise. It does not run infrastructure, measure capacity or replace the lesson’s quiz.
Apply the pattern to two situations. Select one option in each situation to build a decision record. Every option and its consequence stays visible, and you can change your choices.
When it helps—and what it costs
Use it when many objects repeat a significant amount of safely shareable state and memory measurements justify pooling it.
Shared mutable intrinsic state can change many objects unexpectedly. A pool needs a lifetime and eviction strategy; unlimited retained variants can waste memory. The lookup and indirection cost can outweigh savings for small objects.
Distinguish the neighbouring patterns
Prototype copies an exemplar to create a new object. Flyweight deliberately shares suitable state. Singleton limits an instance within a scope and is not a general memory-sharing strategy.
Follow copying versus sharing, scoped instance lifetime, memory limits and eviction to compare the specific responsibility before combining patterns.
Check your pattern reasoning
Check your pattern reasoning
Name the responsibility before choosing the pattern
For Flyweight, describe the problem, the participating roles and the observable contract. Use the example as a starting point and test the boundaries identified in the trade-offs. A pattern name alone does not establish correctness or performance.
Return to the design-pattern guide to compare families, or apply the idea alongside memory limits and eviction.
Reaching the recap and completing the quizzes are separate milestones.