Flyweight

The term comes from the boxing weight classwith the same name. Often some parts of the object state can be sharedand it's common to put them in external data structures and pass themto the flyweight objects temporarily when they are used.

A classic example usage of the flyweight pattern are 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 glyphobject containing its font outline, font metrics, and other formattingdata, but this would amount to hundreds or thousands of bytes for eachcharacter. Instead, for every character there might be a referenceto a flyweight glyph object shared by every instance of the samecharacter in the document; only the position of each character (in thedocument and/or the page) would need to be stored internally.

 

There are cases in programming where it seems that you need to
generate a very large number of small class instances to represent data.
Sometimes you can greatly reduce the number of different classes that you
need to instantiate if you can recognize that the instances are fundamentally
the same except for a few parameters. If you can move those variables outside
the class instance and pass them in as part of a method call, the number of
separate instances can be greatly reduced.
The Flyweight design pattern provides an approach for handling such
classes. It refers to the instance’s intrinsic data that makes the instance
unique, and the extrinsic data which is passed in as arguments. The Flyweight
is appropriate for small, fine-grained classes like individual characters or
icons on the screen. For example, if you are drawing a series of icons on the
screen in a folder window, where each represents a person or data file, it does
not make sense to have an individual class instance for each of them that
remembers the person’s name and the icon’s screen position. Typically these
icons are one of a few similar images and the position where they are drawn
is calculated dynamically based on the window’s size in any case.
In another example in Design Patterns, each character in a font is
represented as a single instance of a character class, but the positions where
the characters are drawn on the screen are kept as external data so that there
needs to be only one instance of each character, rather than one for each
appearance of that character.

 

Flyweights are sharable instances of a class. It might at first seem that
each class is a Singleton, but in fact there might be a small number of
instances, such as one for every character, or one for every icon type. The
number of instances that are allocated must be decided as the class instances
are needed, and this is usually accomplished with a FlyweightFactory class.
This factory class usually is a Singleton, since it needs to keep track of
whether or not a particular instance has been generated yet. It then either
returns a new instance or a reference to one it has already generated.
To decide if some part of your program is a candidate for using
Flyweights, consider whether it is possible to remove some data from the
class and make it extrinsic. If this makes it possible to reduce greatly the

number of different class instances your program needs to maintain, this
might be a case where Flyweights will help.

 

Participants:

• Flyweight: declares an interface through which flyweights can receive and act on extrinsic state.
• ConcreteFlyweight:implements the Flyweight interface and adds storage for intrinsicstate, if any. A ConcreteFlyweight object must be sharable. Any stateit stores must be intrinsic; that is, it must be independent of theConcreteFlyweight object's context.
• UnsharedConcreteFlyweight:not all Flyweight subclasses need to be shared. The Flyweight interfaceenables sharing; it doesn't enforce it. It's common forUnsharedConcreteFlyweight objects to have ConcreteFlyweight objects aschildren at some level in the flyweight object structure (as the Rowand Column classes have).
• FlyweightFactory: creates andmanages flyweight objects, ensuring that flyweights are sharedproperly. When a client requests a flyweight, the FlyweightFactoryobject supplies an existing instance or creates one, if none exists.
• Client: maintains a reference to flyweight(s), and computes (or stores) their extrinsic state.

Collaborations:

• Statethat a flyweight needs to function must be characterized as eitherintrinsic or extrinsic. Intrinsic state is stored in theConcreteFlyweight object; extrinsic state is stored or computed byClient objects. Clients pass this state to the flyweight when theyinvoke its operations.
• Clients should not instantiateConcreteFlyweights directly. Clients must obtain ConcreteFlyweightobjects exclusively from the FlyweightFactory object to ensure they areshared properly.