Flyweight Design Pattern

Definition

Use sharing to support large numbers of fine-grained objects efficiently.  (dofactory)

• Flyweight declares an interface through which flyweights can receive and act on extrinsic state.
• ConcreteFlyweight implements the Flyweight interface and adds storage for intrinsic state, if any. A ConcreteFlyweight object must be sharable. Any state it stores must be intrinsic, that is, it must be independent of the ConcreteFlyweight object's context.
• UnsharedConcreteFlyweight not all Flyweight subclasses need to be shared. The Flyweight interface enables sharing, but it doesn't enforce it. It is common for UnsharedConcreteFlyweight objects to have ConcreteFlyweight objects as children at some level in the flyweight object structure (as the Row and Column classes have).
• FlyweightFactory creates and manages flyweight objects and ensures that flyweight are shared properly. When a client requests a flyweight, the FlyweightFactory objects assets an existing instance or creates one, if none exists.
• Client maintains a reference to flyweight(s) and computes or stores the extrinsic state of flyweight(s).

Each “flyweight” object is divided into two pieces: the state-dependent (extrinsic) part, and the state-independent (intrinsic) part. Intrinsic state is stored (shared) in the Flyweight object. Extrinsic state is stored or computed by client objects, and passed to the Flyweight when its operations are invoked.

Applicability

• The flyweight pattern applies to a program using a huge number of objects that have part of their internal state in common where the other part of state can vary. The pattern is used when the larger part of the object's state can be made extrinsic (external to that object).
• The Motif GUI strategy of replacing heavy-weight widgets with light-weight gadgets.
• The classic example of the Flyweight pattern is the representation of a character in a word processor. Rather than each character having seperate glyph objects that represent the font and formatting data, each character could have a reference to a flyweight glyph object shared by every instance of the same cahracter in the document. In this case, the character need only store it's position in the the document, rather than it's entire formatting information.

Consequences

• Use sharing to support large numbers of fine-grained objects efficiently.
• Flyweight pattern saves memory by sharing flyweight objects among clients. The amount of memory saved generally depends on the number of flyweight categories saved

Downsides

• One of the drawbacks of this pattern is that all instances of the class are related, so single instance of the class will not be able to behave independently from other instances.

Sample Code

Sample Output:

Related Patterns

• Whereas Flyweight shows how to make lots of little objects, Facade shows how to make a single object represent an entire subsystem.
• Flyweight is often combined with Composite to implement shared leaf nodes.
• Terminal symbols within Interpreter’s abstract syntax tree can be shared with Flyweight.
• Flyweight explains when and how State objects can be shared.
• Flyweights are usually created using a Factory and the Singleton is applied to that factory so that for each type or category of flyweights a single instance is returned.
•  State and Strategy objects are usually implemented as Flyweights.

References
http://www.dofactory.com/Patterns/PatternFlyweight.aspx
http://sourcemaking.com/design_patterns/flyweight
http://www.oodesign.com/flyweight-pattern.html
http://java.dzone.com/articles/design-patterns-flyweight

Further readings
http://en.wikipedia.org/wiki/Flyweight_pattern
http://en.wikipedia.org/wiki/Flyweight
http://ayende.com/blog/159713/design-patterns-in-the-test-of-time-flyweight
http://javapapers.com/design-patterns/flyweight-design-pattern/
http://www.blackwasp.co.uk/Flyweight.aspx
http://www.avajava.com/tutorials/lessons/flyweight-pattern.html
http://www.as3dp.com/2007/11/the-flyweight-design-pattern-where-shared-objects-solve-storage-problems/