In computer programming, flyweight is a software design pattern. A flyweight is an object that minimizes memory usage by sharing as much data as possible with other similar objects; it is a way to use objects in large numbers when a simple repeated representation would use an unacceptable amount of memory. Often some parts of the object state can be shared, and it is common practice to hold them in external data structures and pass them to the flyweight objects temporarily when they are used.
Contents
- History
- Immutability and equality
- Concurrency
- Simple implementation
- Example in Python
- Example in Crystal
- References
A classic example usage of the flyweight pattern is the data structures for graphical representation of characters in a word processor. It might be desirable to have, for each character in a document, a glyph object containing its font outline, font metrics, and other formatting data, but this would amount to hundreds or thousands of bytes for each character. Instead, for every character there might be a reference to a flyweight glyph object shared by every instance of the same character in the document; only the position of each character (in the document and/or the page) would need to be stored internally.
Another example is string interning.
In other contexts the idea of sharing identical data structures is called hash consing.
History
According to the textbook Design Patterns: Elements of Reusable Object-Oriented Software, the flyweight pattern was first coined and extensively explored by Paul Calder and Mark Linton in 1990 to efficiently handle glyph information in a WYSIWYG document editor, although similar techniques were already used in other systems, e.g., an application framework by Weinand et al. (1988).
Immutability and equality
To enable safe sharing, between clients and threads, Flyweight objects must be immutable. Flyweight objects are by definition value objects. The identity of the object instance is of no consequence therefore two Flyweight instances of the same value are considered equal.
Example in C# (note Equals and GetHashCode overrides as well as == and != operator overloads):
Concurrency
Special consideration must be made in scenarios 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. This option is only viable if the equality criterion is met.
Simple implementation
Flyweight allows you to share bulky data that are common to each object. In other words, if you think that same data is repeating for every object, you can use this pattern to point to the single object and hence can easily save space. Here the FlyweightPointer creates a static member Company, which is used for every object of MyObject.
Example in Python
Attributes can be defined at the class-level instead of only for instances in Python because classes are first-class objects in the language—meaning there are no restrictions on their use as they are the same as any other object. New-style class instances store instance data in a special attribute dictionary instance.__dict__. By default, accessed attributes are first looked-up in this __dict__, and then fallback to the instance's class attributes next. In this way, a class can effectively be a kind of Flyweight container for its instances.
Although Python classes are mutable by default, immutability can be emulated by overriding the class's __setattr__ method so that it disallows changes to any Flyweight attributes.
Example in Crystal
Output
Serving Cappuchino to table 2 Serving Frappe to table 1 Serving Espresso to table 1 Serving Frappe to table 897 Serving Cappuccino to table 97 Serving Frappe to table 3 Serving Espresso to table 3 Serving Cappuccino to table 3 Serving Espresso to table 96 Serving Frappe to table 552 Serving Cappuccino to table 121 Serving Espresso to table 121 Total CoffeeFlavor made: 4