Understanding Flyweight Design Pattern: When and How to Use

Introduction and Core Concepts

The flyweight design pattern is a structural design pattern that focuses on minimizing memory usage by sharing as much data as possible among similar objects. It is particularly valuable when an application needs to create a large number of objects that share common state, where the sheer volume of instances would otherwise exhaust available memory. Instead of storing identical data in every object, the flyweight design pattern extracts the shared portion and stores it once, allowing thousands or even millions of objects to reference the same underlying data.

At its heart, the flyweight design pattern is about separating intrinsic and extrinsic state. Intrinsic state is the data that is shared and immutable — it is independent of the flyweight's context and can be stored within the flyweight object itself. Extrinsic state, on the other hand, is context-dependent and varies with each use of the flyweight; it is not stored inside the flyweight but is instead passed in by the client when needed. This separation is what enables the massive memory savings that make the pattern so powerful in resource-constrained environments.

Why does the flyweight design pattern matter today? Modern software systems frequently deal with enormous object graphs. Consider a text editor rendering a document with 100,000 characters, a game engine displaying a forest with 1,000,000 trees, or a web browser managing thousands of DOM elements with similar styles. Creating a distinct object for each entity with all its data duplicated would be prohibitively expensive. The flyweight design pattern provides an elegant solution by ensuring that the common, heavyweight parts of these objects are shared, while only the lightweight, varying parts are kept separately. Understanding this pattern is essential for any developer building high-performance, scalable systems where memory efficiency directly impacts user experience and operational cost.

Intrinsic vs. Extrinsic State

Intrinsic state includes properties like the character symbol, font family, or tree texture — values that are identical across many instances and never change after creation. Because this state is immutable, it can be safely shared among many contexts without risk of unintended side effects. The flyweight object encapsulates this intrinsic state and is typically created once and reused many times.

Extrinsic state includes properties like character position, font size variation, or tree coordinates — values that are unique to each occurrence and must be supplied externally. The client code is responsible for maintaining extrinsic state and passing it to the flyweight when invoking its operations. This division of responsibility is the key insight that allows the flyweight design pattern to achieve its efficiency without sacrificing flexibility.

When to Consider the Flyweight Pattern

The flyweight design pattern is most effective when several conditions are met: the application creates a very large number of objects, the storage costs are high due to the quantity of objects, most object state can be made extrinsic, many groups of objects may be replaced by relatively few shared objects once extrinsic state is removed, and the application does not depend on object identity. If these conditions apply, the pattern can reduce memory consumption by an order of magnitude. If they do not, the added complexity of managing a flyweight factory and extrinsic state may outweigh the benefits.

How It Works

The mechanism of the flyweight design pattern revolves around a central Flyweight Factory that controls the creation and sharing of flyweight objects. Instead of clients instantiating flyweights directly with a constructor, they request them from the factory. The factory maintains an internal pool or cache, often implemented as a dictionary or hash map, that maps intrinsic state keys to existing flyweight instances. When a request arrives, the factory checks whether a flyweight with the requested intrinsic state already exists. If it does, the existing instance is returned; if not, a new flyweight is created, added to the pool, and then returned.

This pooling mechanism ensures that for any given intrinsic state, there is at most one flyweight object in memory. The clients then combine this shared flyweight with their own extrinsic state to perform operations. For example, a character flyweight containing the glyph data for the letter 'A' in Arial font can be shared across every occurrence of 'A' in Arial throughout a document. Each occurrence supplies its own position and color as extrinsic state when calling the flyweight's `render` method. The flyweight itself remains stateless with respect to position, making it reusable.

Conceptually, the pattern can be visualized as two layers. The bottom layer is the small set of shared flyweight objects managed by the factory — this is the intrinsic, immutable core. The top layer is the much larger set of contexts or clients that hold references to these flyweights plus their own extrinsic data. The relationship is many-to-one: many contexts point to one flyweight. This structure dramatically reduces the total number of objects and the total memory footprint, especially when the ratio of contexts to unique flyweights is high.

Key Participants

The classic UML structure for the flyweight design pattern includes four main participants. The Flyweight interface declares methods through which flyweights can receive and act on extrinsic state. ConcreteFlyweight implements the Flyweight interface and stores intrinsic state. UnsharedConcreteFlyweight is an optional participant for flyweights that are not shared, though it is rarely needed in practice. The FlyweightFactory creates and manages flyweight objects and ensures proper sharing. Finally, the Client maintains references to flyweights and computes or stores extrinsic state.

The Role of Immutability

Immutability is critical for correctness. Since a single flyweight instance is shared among many clients, any mutation of its intrinsic state would affect all clients simultaneously, leading to subtle and hard-to-debug errors. Therefore, flyweight objects should be designed as immutable after construction. In languages like Python, this can be enforced by not providing setters, using `__slots__`, or making attributes read-only. This immutability guarantee allows safe concurrent sharing without complex synchronization, although the factory itself may still require thread safety.

Implementation

Implementing the flyweight design pattern in Python is straightforward thanks to Python's dynamic nature and built-in dictionary types for caching. The core implementation typically involves a Flyweight class that holds intrinsic state, a Factory class that manages the pool, and client code that supplies extrinsic state. Python's `__new__` method or a simple factory method can be used to control instantiation, but an explicit factory class is clearer and more maintainable for most applications.

The following example demonstrates the canonical structure. We define a `CharacterFlyweight` that stores the intrinsic character glyph and font data, and a `CharacterFactory` that ensures each unique character-font combination is created only once. Note how the flyweight's `render` method accepts extrinsic state such as position and color as parameters rather than storing them internally.

class CharacterFlyweight:
    """Flyweight storing intrinsic state: character and font."""
    __slots__ = ('char', 'font', 'glyph_data')

    def __init__(self, char: str, font: str):
        self.char = char
        self.font = font
        # Simulate heavy glyph data that is expensive to create
        self.glyph_data = f"Glyph({char},{font})::bitmap_data"

    def render(self, extrinsic_state: dict) -> None:
        """Operation requiring extrinsic state (position, size, color)."""
        x = extrinsic_state['x']
        y = extrinsic_state['y']
        color = extrinsic_state['color']
        print(f"Rendering '{self.char}' in {self.font} at ({x},{y}) "
              f"with color {color} using {self.glyph_data}")


class CharacterFactory:
    """Flyweight Factory managing the pool of shared flyweights."""
    def __init__(self):
        self._flyweights: dict[tuple, CharacterFlyweight] = {}

    def get_flyweight(self, char: str, font: str) -> CharacterFlyweight:
        key = (char, font)
        if key not in self._flyweights:
            print(f"Factory: Creating new flyweight for {key}")
            self._flyweights[key] = CharacterFlyweight(char, font)
        else:
            print(f"Factory: Reusing existing flyweight for {key}")
        return self._flyweights[key]

    def count(self) -> int:
        return len(self._flyweights)

This implementation highlights the separation of concerns. The `CharacterFlyweight` is lightweight in terms of per-instance overhead because its heavy `glyph_data` is shared. The factory encapsulates the caching logic, so clients do not need to know whether they are receiving a new or reused instance. This encapsulation also makes it easy to add optimizations such as LRU eviction or weak references later without changing client code.

A more Pythonic alternative can leverage `functools.lru_cache` or the `__new__` method to make the factory transparent, but an explicit factory is generally preferred for clarity, testability, and the ability to add metrics or lifecycle management. For thread-safe applications, the factory's `get_flyweight` method should be protected with a lock to prevent race conditions where two threads might create duplicate flyweights for the same key simultaneously.

import threading
from weakref import WeakValueDictionary

class ThreadSafeFlyweightFactory:
    """Thread-safe factory using WeakValueDictionary for automatic cleanup."""
    def __init__(self):
        # WeakValueDictionary allows garbage collection when no clients hold refs
        self._pool: WeakValueDictionary = WeakValueDictionary()
        self._lock = threading.Lock()

    def get_tree_type(self, name: str, color: str, texture: str):
        key = (name, color, texture)
        with self._lock:
            obj = self._pool.get(key)
            if obj is None:
                obj = TreeType(name, color, texture)
                self._pool[key] = obj
                print(f"Created new TreeType: {key}")
            return obj

class TreeType:
    """Flyweight containing intrinsic state for trees."""
    def __init__(self, name: str, color: str, texture: str):
        self.name = name
        self.color = color
        self.texture = texture  # Heavy object, e.g., image data

    def draw(self, x: int, y: int) -> None:
        # Extrinsic state x, y is passed in
        print(f"Drawing {self.name} ({self.color}, {self.texture}) at ({x},{y})")

# Usage ensures memory is reclaimed when Tree objects are deleted

In this second example, we introduce `WeakValueDictionary` to prevent memory leaks. If the factory held strong references forever, flyweights that are no longer needed would never be garbage collected. By using weak references, the flyweight remains in the pool only while at least one client holds a strong reference to it. Once all clients release it, it is automatically removed from the pool. This is a crucial optimization for long-running applications where the set of intrinsic states may evolve over time.

Step-by-Step Example

To make the flyweight design pattern concrete, let us walk through a complete example: rendering a forest in a game. Suppose we need to display 1,000,000 trees. Each tree has a type (e.g., Oak, Pine), a color, a texture, and a position (x, y). Without the flyweight pattern, we would create 1,000,000 tree objects, each storing its own copy of the name, color, and texture — even though there may be only 3 distinct tree types. With the flyweight pattern, we share the type information.

Step 1 is to identify intrinsic and extrinsic state. Intrinsic: tree type name, color, texture. These are shared and immutable. Extrinsic: x and y coordinates, which are unique per tree and supplied at draw time. Step 2 is to create the flyweight class `TreeType` to hold intrinsic state and the context class `Tree` to hold extrinsic state plus a reference to the flyweight. Step 3 is to create the factory to manage `TreeType` instances. Step 4 is for the client (the Forest) to use the factory to obtain shared types and create many lightweight Tree contexts.

class TreeType:
    def __init__(self, name: str, color: str, texture: str):
        self.name = name
        self.color = color
        self.texture = texture

    def draw(self, canvas, x: int, y: int) -> None:
        # Intrinsic state used with extrinsic x, y
        canvas.draw_image(self.texture, x, y)


class Tree:
    """Context holding extrinsic state + reference to flyweight."""
    def __init__(self, x: int, y: int, tree_type: TreeType):
        self.x = x
        self.y = y
        self.tree_type = tree_type  # Reference to shared flyweight

    def draw(self, canvas) -> None:
        self.tree_type.draw(canvas, self.x, self.y)


class TreeFactory:
    _tree_types: dict[tuple, TreeType] = {}

    @classmethod
    def get_tree_type(cls, name: str, color: str, texture: str) -> TreeType:
        key = (name, color, texture)
        if key not in cls._tree_types:
            cls._tree_types[key] = TreeType(name, color, texture)
        return cls._tree_types[key]

    @classmethod
    def get_count(cls) -> int:
        return len(cls._tree_types)


class Forest:
    def __init__(self):
        self.trees: list[Tree] = []

    def plant_tree(self, x: int, y: int, name: str, color: str, texture: str) -> None:
        tree_type = TreeFactory.get_tree_type(name, color, texture)
        tree = Tree(x, y, tree_type)
        self.trees.append(tree)

    def draw(self, canvas) -> None:
        for tree in self.trees:
            tree.draw(canvas)

Consider the memory impact. Assume each `TreeType` with texture data consumes 10 KB, and each `Tree` context with x, y and a reference consumes 32 bytes. Without flyweight: 1,000,000 * (10 KB + 32 bytes) ≈ 10 GB. With flyweight and 3 types: 3 * 10 KB + 1,000,000 * 32 bytes ≈ 30 KB + 32 MB ≈ 32 MB. The savings are over 300x. This walkthrough shows why the flyweight design pattern is indispensable for large-scale simulations, particle systems, and any domain where object count is massive but variation is limited.

To verify the sharing, we can plant trees and inspect the factory count. Even after planting 1,000,000 trees, `TreeFactory.get_count()` will return 3. We can also check object identity with `is`: two trees of the same type will have `tree1.tree_type is tree2.tree_type` evaluate to `True`, confirming they share the exact same instance in memory. This identity check is a useful debugging technique when implementing the flyweight design pattern.

# Client code demonstrating massive sharing
forest = Forest()
# Plant 1M trees with only 3 types
import random

for _ in range(100000):
    forest.plant_tree(random.randint(0, 1000), random.randint(0, 1000),
                      "Oak", "Green", "oak_texture.png")
    forest.plant_tree(random.randint(0, 1000), random.randint(0, 1000),
                      "Pine", "DarkGreen", "pine_texture.png")
    forest.plant_tree(random.randint(0, 1000), random.randint(0, 1000),
                      "Birch", "LightGreen", "birch_texture.png")

print(f"Total trees planted: {len(forest.trees)}")  # 300000
print(f"Unique TreeTypes created: {TreeFactory.get_count()}")  # 3

# Verify sharing
t1 = forest.trees[0].tree_type
t2 = forest.trees[3].tree_type
print(t1 is t2)  # True if same type, confirms flyweight reuse
# Memory check: check if extrinsic state affects flyweight count
assert TreeFactory.get_count() == 3
print("Flyweight sharing verified: 300k contexts -> 3 flyweights")

Complexity Analysis

Analyzing the complexity of the flyweight design pattern requires distinguishing between the cost of operations on the flyweight factory and the overall memory complexity of the system. The pattern does not change the asymptotic time complexity of business operations like rendering or drawing — those remain dependent on the number of contexts. Instead, it optimizes space complexity and can affect the time complexity of object creation due to caching.

Factory lookup is typically O(1) average case when using a hash map or dictionary, as in Python's `dict`. Creation of a new flyweight is O(1) as well, but involves the cost of initializing intrinsic state, which may be expensive if it involves loading textures or parsing fonts. Subsequent requests for the same intrinsic state are served from the cache in O(1) time without re-initialization cost. This makes the amortized cost of obtaining a flyweight very low when reuse is high.

Space complexity is where the flyweight design pattern shines. Let N be the total number of contexts (e.g., trees) and M be the number of unique intrinsic states (e.g., tree types), where M << N. Without the pattern, space is O(N * (S_intrinsic + S_extrinsic)), where S_intrinsic and S_extrinsic are the sizes of intrinsic and extrinsic state. With the pattern, space becomes O(M * S_intrinsic + N * S_extrinsic). When S_intrinsic is large and M is small, this is a dramatic reduction. The factory itself adds O(M) overhead for the pool dictionary, which is negligible compared to the savings.

It is important to note that the worst-case time for factory lookup can degrade to O(n) if the hash function is poor and many keys collide, but with Python's robust dictionary implementation, this is extremely rare in practice. Similarly, if intrinsic state initialization involves I/O, such as loading an image from disk, the worst-case creation time could be dominated by I/O latency. This can be mitigated by lazy loading or pre-warming the factory. Overall, the flyweight design pattern trades a small amount of time overhead for factory lookup and extrinsic state management for a massive reduction in memory usage, making it a net win when N is large.

Variations and Optimizations

While the classic flyweight design pattern is effective, several variations and optimizations have emerged to address specific challenges in modern applications. One common variation is the use of immutable flyweights combined with object pooling for extrinsic state. Instead of creating new dictionaries or objects to hold extrinsic state on every operation, a pool of extrinsic state objects can be reused, further reducing garbage collection pressure in languages like Python or Java.

Another important optimization is combining the flyweight design pattern with the Factory Method or Singleton patterns. The Flyweight Factory is often implemented as a Singleton to ensure a single global pool, preventing duplicate pools in different parts of the application. However, this should be used judiciously, as Singletons can make testing harder. An alternative is dependency injection, where the factory is created once and passed to clients that need it, preserving testability while still ensuring sharing.

For memory-sensitive applications, integrating weak references, LRU (Least Recently Used) eviction, or soft references is crucial. A pure strong-reference cache will grow indefinitely as new intrinsic states are encountered, potentially leading to a memory leak if the set of intrinsic states is unbounded. By using `WeakValueDictionary` in Python or `WeakHashMap` in Java, flyweights that are no longer in use can be automatically reclaimed. For cases where intrinsic states are expensive to recreate, an LRU cache with a fixed maximum size provides a bounded memory guarantee while keeping the most frequently used flyweights in memory.

Composite Flyweights

In some systems, flyweights themselves may be composed of other flyweights. For example, a document flyweight representing a paragraph might be composed of character flyweights. This composite structure allows hierarchical sharing, where both the paragraph-level formatting and the character-level glyphs are shared. Implementing composite flyweights requires careful design to ensure that extrinsic state is correctly propagated through the hierarchy without breaking encapsulation.

Flyweight with Strategy and State

The flyweight design pattern is often combined with the Strategy pattern to allow flyweights to have varying behavior without storing state. The intrinsic state can include a strategy object that defines how the flyweight operates on extrinsic state. For instance, different tree types might have different growth algorithms encapsulated as strategies. This keeps the flyweight itself stateless while still allowing behavioral variation, preserving the sharing benefits.

Real-World Applications

The flyweight design pattern is not merely academic; it is widely used in production systems where performance and memory efficiency are critical. One of the most classic examples is in text editors and word processors. Applications like Microsoft Word, Google Docs, and VS Code need to handle documents with hundreds of thousands of characters. Each character could be an object with font, size, style, and position. By using the flyweight design pattern, the editor stores character glyph data once per font-style combination and reuses it across the entire document, enabling smooth editing of large files without excessive memory consumption.

In game development, the pattern is essential for rendering large numbers of similar entities. A forest with millions of trees, a battlefield with thousands of soldiers, or a particle system with countless sparks all benefit from flyweight sharing. Game engines like Unity and Unreal Engine use flyweight-like techniques internally for instanced rendering, where a single mesh and material (intrinsic state) is drawn many times with different transformation matrices (extrinsic state) in a single draw call, dramatically improving GPU performance.

Web browsers and UI frameworks also rely heavily on the flyweight concept. Browsers use it to manage CSS styles and DOM rendering. Many DOM elements share the same computed styles; storing a separate style object for each element would be wasteful. Instead, browsers intern style data and share it. Similarly, Java's `String` interning and Python's string interning for small strings are flyweight implementations at the language level. Database connection pools, thread pools, and web server request handlers also exhibit flyweight characteristics by reusing expensive resources.

Beyond these, flyweight is used in financial systems for representing market data ticks where many instruments share similar metadata, in network routers for packet classification where many flows share the same routing rules, and in IDEs for syntax highlighting where tokens of the same type share color and font information. Any system that exhibits high object count with low variation is a candidate for the flyweight design pattern, making it a versatile tool for building scalable infrastructure.

Comparison with Alternatives

Choosing the right pattern requires understanding how the flyweight design pattern differs from related approaches. While several patterns aim to optimize resource usage or manage object creation, they do so with different trade-offs and intents. Confusing flyweight with Singleton, Prototype, or Object Pool can lead to inappropriate application and unnecessary complexity.

The Singleton pattern ensures only one instance of a class exists, whereas flyweight ensures one instance per unique intrinsic state — there can be many flyweights, but only one per key. The Prototype pattern creates new objects by cloning existing ones, which is useful when creation is expensive but does not inherently share state among clones. The Object Pool pattern reuses entire objects including extrinsic state, typically for expensive resources like database connections, while flyweight shares only intrinsic state and expects clients to supply extrinsic state. Understanding these distinctions helps select the pattern that best matches the problem's constraints.

In practice, these patterns are often complementary. A Flyweight Factory is frequently implemented as a Singleton to ensure global sharing, and flyweights themselves may be created via Prototype cloning if their intrinsic state is complex to initialize. An Object Pool might be used inside a flyweight to manage extrinsic state objects. The key decision factor is whether your problem is dominated by memory pressure from many similar objects (choose flyweight), by the need for a single global resource (choose Singleton), by expensive creation of diverse objects (choose Prototype), or by expensive acquisition of reusable resources (choose Object Pool).

Common Mistakes and Best Practices

Implementing the flyweight design pattern incorrectly can introduce bugs that are difficult to trace and can even worsen performance. One of the most common mistakes is failing to properly separate intrinsic and extrinsic state. Developers sometimes store extrinsic state inside the flyweight for convenience, which breaks sharing and causes one client's changes to inadvertently affect others. For example, storing a tree's x-coordinate inside the shared `TreeType` would cause all trees of that type to move together. Always audit which fields are truly immutable and shared versus context-dependent.

Another frequent pitfall is making flyweights mutable. If intrinsic state can be modified after creation, sharing becomes unsafe, especially in concurrent environments. A client that modifies a shared flyweight's color will change the color for all other clients using that flyweight. Enforce immutability by using read-only properties, `__slots__` without setters, or by freezing the object after construction. In Python, consider using `@dataclass(frozen=True)` for flyweight classes to get immutability guarantees from the language.

Premature optimization is also a risk. The flyweight design pattern adds complexity: a factory, extrinsic state management, and indirection on every operation. If the application only creates a few hundred objects, or if intrinsic state is small, the overhead may not be justified. Profile memory usage before applying the pattern. Use it when measurements show that object count and memory are genuine bottlenecks, not as a default design for all object creation. Similarly, over-engineering the factory with complex eviction policies when a simple dictionary would suffice can add unnecessary maintenance burden.

Best Practices

• Keep flyweights immutable: Never provide setters for intrinsic state. Make flyweights hashable if they will be used as dictionary keys.
• Make the factory thread-safe: Use locks or concurrent dictionaries if flyweights are accessed from multiple threads. Double-checked locking can reduce contention.
• Use weak references for long-running apps: Prevent memory leaks by allowing unused flyweights to be garbage collected with `WeakValueDictionary` or similar.
• Encapsulate extrinsic state clearly: Use a dedicated context object or dataclass for extrinsic state rather than passing loose dictionaries, improving type safety and readability.
• Measure before and after: Benchmark memory usage with tools like `tracemalloc`, `memory_profiler`, or `pympler` to quantify savings and ensure the pattern delivers value.
• Document intrinsic vs. extrinsic division: Clearly comment which fields are intrinsic and why, so future maintainers do not accidentally move extrinsic state into the flyweight.
• Consider interning for primitives: For strings and small integers, leverage language-level interning instead of building a custom flyweight factory.

Testing flyweight implementations requires special attention. Write tests that verify sharing: requesting the same intrinsic state twice should return the identical object (`is` check). Test that extrinsic state does not leak between contexts, and that concurrent requests do not create duplicates. Mock the factory in client tests to isolate behavior, and test the factory itself for correct caching and eviction.

Interview Questions

Interviewers frequently use the flyweight design pattern to assess understanding of structural patterns, memory optimization, and trade-offs. Expect questions that go beyond definitions to probe practical application and design judgment.

1. How does the flyweight design pattern reduce memory usage, and what is the difference between intrinsic and extrinsic state?

Answer: The flyweight design pattern reduces memory by sharing intrinsic state — the immutable, context-independent data — among many objects. Instead of storing a copy of intrinsic state in each of N objects, it stores M copies (one per unique state) and shares them. Extrinsic state is the varying, context-dependent data that is stored outside the flyweight and passed in when needed. For example, in a text editor, the character glyph is intrinsic and shared, while the position is extrinsic and supplied by the client. This reduces memory from O(N * (intrinsic+extrinsic)) to O(M * intrinsic + N * extrinsic), which is significant when M << N.

2. Implement a flyweight factory for a simple use case in Python. How would you ensure thread safety?

Answer: Describe or write a factory with a dictionary cache and a lock. Explain that without synchronization, two threads could simultaneously check `if key not in cache` and both create a new instance, violating the sharing guarantee. Solution: wrap the check-and-create block with `threading.Lock`, or use double-checked locking for performance. Mention `WeakValueDictionary` for automatic cleanup and that in CPython the GIL provides some protection but explicit locks are still needed for correctness. Provide code similar to the `ThreadSafeFlyweightFactory` example above.

3. When would you NOT use the flyweight design pattern?

Answer: Do not use flyweight when the number of objects is small, when intrinsic state is not shareable or is mostly unique (M ≈ N), when object identity matters, or when extrinsic state is large and complex to manage externally. The pattern adds indirection and factory overhead, so if memory is not a constraint, the added complexity hurts maintainability without benefit. Also avoid it if flyweights would need to be mutable, as sharing mutable state is error-prone.

4. Compare flyweight with Singleton and Object Pool. Can they be used together?

Answer: Flyweight shares one instance per key (many flyweights, one per intrinsic state), Singleton ensures one instance total, and Object Pool reuses entire objects including extrinsic state to avoid creation cost. They can be combined: a Flyweight Factory is often a Singleton to ensure a single global cache. An Object Pool might manage the extrinsic context objects. The key distinction is intent: flyweight optimizes memory via sharing, Singleton controls global access, and Object Pool optimizes creation time via reuse.

5. What are the concurrency challenges with flyweight, and how do you handle them?

Answer: The main challenge is safe publication and creation of flyweights. Since flyweights are immutable, they are inherently thread-safe after creation, but the factory's cache is a shared mutable structure that requires synchronization. Solutions include using locks, concurrent hash maps, or immutable factory initialization (pre-populating all flyweights at startup). Also, extrinsic state must not be stored in the flyweight, otherwise concurrent clients would race on mutable shared state. Emphasize that immutability of flyweights is what makes sharing safe, and all mutability must be confined to extrinsic context objects.