How does the Flyweight pattern differ from an object pool, a cache, memoization, and Singleton — patterns that also hand out reused instances?

## Why these get confused Every one of these patterns results in "you get back an object that already existed". The distinctions are in **purpose**, **mutability**, **concurrency of use**, and **what happens if the reuse disappears**. ## The four (plus one) compared | | Flyweight | Object pool | Cache / memoization | Singleton | Multiton / registry | |---|---|---|---|---|---| | **Goal** | Cut memory across many fine-grained objects | Amortize expensive construction/acquisition | Avoid recomputation or slow I/O | Guarantee exactly one instance | Named lookup of one instance per key | | **Instance count** | One per distinct intrinsic value | A bounded set, reused over time | One per cached key, evictable | Exactly one | One per key | | **Mutability** | Immutable, required | Mutable, must be reset on return | Values typically immutable | Usually mutable state | Varies | | **Concurrent use** | Many clients at once | Exclusive: one borrower at a time | Many readers at once | Many clients at once | Many clients at once | | **Lifecycle** | Lives while referenced/interned | Borrow → use → return | Insert → hit → evict | Program lifetime | Registration lifetime | | **If reuse vanished** | Correct but memory-hungry | Correct but slow, maybe resource-exhausting | Correct but slow | *Incorrect* — invariant violated | Depends | That last row is the fastest discriminator in an interview. **Flyweight and cache are optimizations** — remove the sharing and the program is still correct, just fatter or slower. **Singleton is a correctness constraint** — remove it and you have violated the design. **Pool** sits between: usually a performance/resource-limit device, but a leaked or double-returned object is a correctness bug. ## Flyweight vs Object Pool — the most common confusion The crucial difference is **simultaneous versus exclusive use**. - Flyweight objects are shared *at the same time* by unrelated clients precisely *because* they are immutable and stateless with respect to context. Ten thousand trees render from one shared mesh concurrently. - Pooled objects are **checked out** and used *exclusively*, then returned and reused by someone else. A database connection carries per-user state (transaction, session settings), so two clients using it at once would be a bug. Pools therefore need borrow/return protocol, reset-on-return, leak detection for un-returned objects, sizing, and often validity checks for stale resources. A useful phrase: *Flyweight shares; a pool recycles.* ## Flyweight vs Cache/Memoization A flyweight factory literally contains a cache, so the mechanisms overlap. The difference is in the contract and the intent: - A memoization cache exists so you do not recompute `f(x)`. It is free to evict; a miss just costs time. Nothing depends on getting *the same instance* back. - A flyweight factory exists so that a value has **one canonical instance**. Callers may (implicitly or explicitly) depend on that: reference-equality comparisons, identity-keyed side tables, per-instance locks. If you bolt eviction onto a flyweight factory you weaken that guarantee and must make sure no caller relies on identity. So: caches optimize *time* and tolerate eviction; flyweight factories optimize *space* and tend to promise identity. ## Flyweight vs Singleton Singleton constrains a *class* to one instance and often carries global mutable state (a registry, a configuration holder). Flyweight yields one instance *per value*, with no global-state connotation, and the instances are values, not services. The pattern that most resembles "Singleton, but keyed" is **Multiton** or a **registry** — and a flyweight factory can look exactly like one. The distinguishing question is again purpose: is the goal deduplicating a large object population (Flyweight), or providing named access to a service instance (registry/multiton)? ## Flyweight vs plain value objects / interning A modern language may give you value objects, records, or a runtime that automatically deduplicates strings. If the language can represent a value inline without an object header, Flyweight's benefit shrinks — the duplication you were removing may not exist. Conversely, "interning" is exactly Flyweight's factory mechanism applied to a single value type, and it is often the pragmatic 80% solution: intern the one repeated field rather than restructuring the whole object. ## Combinations you will see in real systems - A pool of buffers, where each buffer holds references to shared flyweight schema objects. - A flyweight factory whose backing map is a bounded cache, deliberately trading identity for a memory ceiling. - Enum constants: a precomputed flyweight table that is also, per constant, effectively a singleton. - Columnar storage: dictionary encoding is Flyweight moved from the object graph into the data layout.