What is the Flyweight Pattern?
Learn the Flyweight pattern — intrinsic vs extrinsic state and memory-efficient sharing — with a Java glyph example and interview Q&A.
Expected Interview Answer
The Flyweight pattern minimizes memory usage by sharing immutable, common state across many similar objects instead of storing that state redundantly in each individual instance.
Each object’s data is split into intrinsic state, which is context-independent and safely shared, and extrinsic state, which is context-specific and supplied by the client at the point of use. A flyweight factory ensures that objects with identical intrinsic state are reused rather than recreated, typically via a cache keyed on that state. This is most valuable when an application needs to create a very large number of fine-grained objects, such as characters in a text editor or trees in a forest simulation, where per-object overhead would otherwise be prohibitive. The tradeoff is added complexity: extrinsic state must be threaded through method calls or a context object rather than living inside the object itself.
- Dramatically reduces memory for large numbers of similar objects
- Separates shareable intrinsic state from per-use extrinsic state
- Centralizes object creation through a factory that reuses instances
- Scales systems that would otherwise be object-count bound
AI Mentor Explanation
A stadium doesn’t manufacture a unique physical ball design for every single delivery bowled in a match; it reuses the same handful of ball objects (intrinsic state: seam, weight, brand) across hundreds of deliveries, while each delivery’s speed and line (extrinsic state) is tracked separately per ball. That separation is the Flyweight pattern: shared, unchanging data lives in one reused object, while per-event data is supplied externally rather than duplicated inside a new object every time.
Step-by-Step Explanation
Step 1
Split intrinsic vs extrinsic state
Identify which fields are shareable across instances and which are context-specific per use.
Step 2
Define the flyweight interface
Operations accept extrinsic state as parameters rather than storing it internally.
Step 3
Build a flyweight factory
Cache and return existing flyweight instances keyed on intrinsic state instead of always constructing new ones.
Step 4
Supply extrinsic state at call time
Clients or a context object pass the varying data into flyweight methods on each use.
What Interviewer Expects
- Correct definition of intrinsic vs extrinsic state
- Understanding of the factory's role in caching and reuse
- A concrete high-object-count scenario (text editor glyphs, particle systems)
- Awareness of the added complexity tradeoff of threading extrinsic state
Common Mistakes
- Confusing Flyweight with simple caching or object pooling without the intrinsic/extrinsic split
- Making flyweight objects mutable, which breaks safe sharing
- Forgetting extrinsic state must be supplied externally, not stored in the flyweight
- Applying Flyweight where object count is small and memory pressure is not a real problem
Best Answer (HR Friendly)
“The Flyweight pattern saves memory when you need huge numbers of similar objects by sharing the data that’s identical across them and only storing the small bits that actually differ separately. A factory hands out the same shared object instead of creating a new one every time, which keeps memory usage low even with millions of objects.”
Code Example
class Glyph { // intrinsic state: shared, immutable
private final char symbol;
private final String font;
Glyph(char symbol, String font) { this.symbol = symbol; this.font = font; }
void render(int x, int y) { // extrinsic state passed in
System.out.println(symbol + " at (" + x + "," + y + ") in " + font);
}
}
class GlyphFactory {
private static final Map<String, Glyph> cache = new HashMap<>();
static Glyph get(char symbol, String font) {
String key = symbol + font;
return cache.computeIfAbsent(key, k -> new Glyph(symbol, font));
}
}
Glyph g1 = GlyphFactory.get('a', "Arial");
Glyph g2 = GlyphFactory.get('a', "Arial"); // same shared instance
g1.render(10, 20);Follow-up Questions
- How do you decide which fields are intrinsic versus extrinsic?
- What role does the flyweight factory play in ensuring sharing?
- Why must flyweight objects be immutable?
- When is Flyweight not worth the added complexity?
MCQ Practice
1. The Flyweight pattern reduces memory usage by?
Flyweight shares immutable intrinsic state across instances instead of duplicating it in each object.
2. Extrinsic state in the Flyweight pattern is?
Extrinsic state varies per use and is passed into flyweight methods rather than stored internally.
3. Flyweight is most beneficial when?
Flyweight pays off when object count is large enough that per-object overhead becomes a real memory problem.
Flash Cards
Flyweight pattern in one line? — Share immutable intrinsic state across many objects to reduce memory usage.
Intrinsic vs extrinsic state? — Intrinsic is shared and context-independent; extrinsic is per-use and supplied externally.
Who ensures reuse? — A flyweight factory that caches instances keyed on intrinsic state.
Classic example? — Character glyphs in a text editor sharing font and shape data.