How do you decide whether applying the Flyweight pattern will actually pay off, and when should you reject it?

## Start from a measurement, not a pattern Flyweight is an **optimization**, and the first rule of optimization applies: prove the cost. A heap dump or allocation profile should show that instances of one class dominate retained memory and that their field values repeat heavily. If you cannot show that, do not apply the pattern. ## The cost model Let: - `N` = number of occurrences in memory at peak - `K` = number of *distinct* intrinsic value combinations - `S_i` = bytes of intrinsic state - `S_e` = bytes of extrinsic state - `H` = per-object overhead (header, alignment/padding — commonly 12–16 bytes, plus padding, in managed runtimes) - `R` = bytes per reference (4 with compressed pointers, 8 without) **Naive:** `N × (H + S_i + S_e)` **Flyweight:** `K × (H + S_i)` + `N × (R + S_e)` + `cacheOverhead(K)` (a hash map entry is not free — typically 32–48 bytes per entry) **Savings ≈ `(N − K) × (H + S_i) − N × R − cacheOverhead(K)`** Three readings fall out immediately: 1. **`N/K` is the leverage.** At `N/K = 2` you are barely ahead and probably behind after overheads. At `N/K = 10,000` the win is enormous. 2. **`S_i` must beat `R`.** If the intrinsic state is a single 4-byte enum, replacing it with a 4- or 8-byte reference saves nothing — you have added indirection for zero benefit. Sharing a 2 MB texture across 100,000 trees is the opposite extreme. 3. **Extrinsic storage matters as much as sharing.** If each occurrence is still a full object with a header and boxed fields, the `N × H` term never goes away. The real wins come when the per-occurrence record collapses to a compact struct, a packed row, or an index into parallel arrays. ## Beyond bytes: the non-memory factors **Object lifetime.** Generational garbage collectors make short-lived allocation extremely cheap. Interning short-lived objects can be *worse* than allocating them: you pay hash+lookup on every acquisition and promote objects into long-lived space, increasing old-generation pressure. Flyweight favours long-lived, simultaneously-live populations. **Allocation rate vs. retained size.** If the profile shows high *churn* but low *retention*, Flyweight is aimed at the wrong problem; escape analysis, reuse in a loop, or avoiding materialization is the fix. **Cache locality.** Sharing can help (a hot flyweight stays in L1/L2 across millions of uses) or hurt (every occurrence now dereferences a pointer into a scattered heap region). Measure; do not assume. **Concurrency.** Shared immutable flyweights are read-safe and can be a genuine win, but the factory itself becomes a shared, potentially contended structure on the hot path. **API damage.** Extrinsic state must be threaded through every operation, so signatures widen and call sites get noisier. This is a permanent, global tax on readability paid for a local, quantifiable benefit. It is the strongest reason to prefer a *representation* change hidden behind the existing API. **Immutability feasibility.** If the domain genuinely requires per-occurrence mutation of what you wanted to share, the pattern is off the table (or is limited to the immutable subset via unshared concrete flyweights). ## Cheaper alternatives to consider first - **Deduplicate one field, not the object.** Interning just the repeated strings or the repeated config object often captures 90% of the win with zero API change. Some runtimes even do automatic string deduplication in the GC. - **Dictionary/columnar encoding.** Store an integer code per row plus one table of distinct values. This is Flyweight applied at the data layer and is usually strictly better for bulk data. - **Packed representations.** Bit-fields, primitive arrays, structure-of-arrays. Frequently beats Flyweight outright because it removes headers entirely. - **Don't materialize.** Stream, paginate, or compute on demand. The cheapest object is the one that never exists. - **Enums / precomputed constants.** For tiny finite key spaces, a static table is Flyweight without a factory, a cache or a leak. ## Rejection checklist Say no when any of these hold: `K` is close to `N`; `S_i` is on the order of a reference; the population is short-lived; total footprint is small in absolute terms; shared state cannot be immutable; the extrinsic side would remain heavyweight; a representation change achieves the same win behind the existing API; or you have no measurement showing the problem is real. ## Saying this in an interview The strong answer is not "Flyweight saves memory". It is: "I would confirm from a heap dump that this class dominates retained size, estimate `N`, `K` and `S_i`, compute the expected saving including reference and map overhead, weigh it against the API cost of threading extrinsic state, and check whether interning a single field or changing the storage layout gets most of the win for none of the design cost."