Editing Flyweight pattern (section)

== Implementation details ==
There are multiple ways to implement the flyweight pattern. One example is mutability: whether the objects storing extrinsic flyweight state can change.

[[Immutable]] objects are easily shared, but require creating new extrinsic objects whenever a change in state occurs. In contrast, mutable objects can share state. Mutability allows better object reuse via the caching and re-initialization of old, unused objects. Sharing is usually nonviable when state is highly variable.

Other primary concerns include retrieval (how the end-client accesses the flyweight), [[caching]] and [[Concurrency (computer science)|concurrency]].

=== Retrieval === 
The [[Factory (object-oriented programming)|factory]] interface for creating or reusing flyweight objects is often a [[Facade pattern|facade]] for a complex underlying system. For example, the factory interface is commonly implemented as a [[Singleton pattern|singleton]] to provide global access for creating flyweights.

Generally speaking, the retrieval algorithm begins with a request for a new object via the factory interface.

The request is typically forwarded to an appropriate [[Cache (computing)|cache]] based on what kind of object it is. If the request is fulfilled by an object in the cache, it may be reinitialized and returned. Otherwise, a new object is instantiated. If the object is partitioned into multiple extrinsic sub-components, they will be pieced together before the object is returned.

=== Caching ===
There are two ways to [[Cache (computing)|cache]] flyweight objects: maintained and unmaintained caches.

Objects with highly variable state can be cached with a [[FIFO (computing and electronics)|FIFO]] structure. This structure maintains unused objects in the cache, with no need to search the cache.

In contrast, unmaintained caches have less upfront overhead: objects for the caches are initialized in bulk at compile time or startup. Once objects populate the cache, the object retrieval algorithm might have more overhead associated than the push/pop operations of a maintained cache.

When retrieving extrinsic objects with immutable state one must simply search the cache for an object with the state one desires. If no such object is found, one with that state must be initialized. When retrieving extrinsic objects with mutable state, the cache must be searched for an unused object to reinitialize if no used object is found. If there is no unused object available, a new object must be instantiated and added to the cache.

Separate caches can be used for each unique subclass of extrinsic object. Multiple caches can be optimized separately, associating a unique search algorithm with each cache. This object caching system can be encapsulated with the [[Chain-of-responsibility pattern|chain of responsibility]] pattern, which promotes loose coupling between components.

=== Concurrency ===
Special consideration must be taken into account where flyweight objects are created on multiple threads. If the list of values is finite and known in advance, the flyweights can be instantiated ahead of time and retrieved from a container on multiple threads with no contention. If flyweights are instantiated on multiple threads, there are two options:

# Make flyweight instantiation single-threaded, thus introducing contention and ensuring one instance per value.
# Allow concurrent threads to create multiple flyweight instances, thus eliminating contention and allowing multiple instances per value.

To enable safe sharing between clients and threads, flyweight objects can be made into [[immutable]] [[value object]]s, where two instances are considered equal if their values are equal.