Flyweight Design Pattern
Links
The Flyweight design motif
The informal description: Excerpts from [Gamma et al. 1995] (adapted for
this purpose):
Intent: Use sharing to support large numbers of fine-grained objects efficiently.
Structure: Original OMT diagram converted to UML (Why
and How?):
Participants:
- 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; it doesn't enforce it. It's 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, ensuring that flyweights are shared properly. When a client requests a flyweight, the FlyweightFactory object 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:
- State that a flyweight needs to function must be characterized as either intrinsic or extrinsic. Intrinsic state is stored in the ConcreteFlyweight object; extrinsic state is stored or computed by Client objects. Clients pass this state to the flyweight when they invoke its operations.
- Clients should not instantiate ConcreteFlyweights directly. Clients must obtain ConcreteFlyweight objects exclusively from the FlyweightFactory object to ensure they are shared properly.
Formal specification
See also:
