Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
"Use sharing to support large numbers of fine-grained objects efficiently." (Gamma, E., R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995)
Some applications could benefit from using objects throughout their design, but a naïve implementation would be prohibitively expensive. For example, most document editor implementations have text formatting and editing facilities that are modularized to some extent. Object-oriented document editors typically use objects to represent embedded elements like tables and figures. However, they usually stop short of using an object for each character in the document because of the cost as documents may require hundreds of thousands of character objects, which consume lots of memory and may incur unacceptable run-time overhead. A flyweight is a shared object that can be used in multiple contexts simultaneously. The flyweight acts as an independent object in each context--its indistinguishable from an instance of the object thats not shared. The key concept here is the distinction between intrinsic and extrinsic state. Intrinsic state is stored in the flyweight; it consists of information thats independent of the flyweights context, thereby making it sharable. Extrinsic state depends on and varies with the flyweights context and therefore cant be shared. Client objects are responsible for passing extrinsic state to the flyweight when it needs it. A document editor can create a flyweight for each letter of the alphabet. Logically there is an object for every occurrence of a given character in the document. Physically there is one shared flyweight object per character, and it appears in different contexts in the document structure. The class structure could be: Glyph (Flyweight in the thumbnail) as an abstract class for graphical objects, some of which may be flyweights. Operations that may depend on extrinsic state have it passed to them as a parameter. A flyweight representing the letter "a" only stores the corresponding character code; it doesnt need to store its location or font. Clients supply the context-dependent information that the flyweight needs to draw itself. For example, a Row glyph (UnsharedConcreteFlyweight in the thumbnail) knows where its children should draw themselves so that they are tiled horizontally. It can pass each child its location in the draw request.
This pattern has been used on the following systems: InterViews 3.0 document editor called Doc uses glyph objects to represent each character in the document. The editor builds one Glyph instance for each character in a particular style. Therefore, only position is extrinsic making Doc fast. (Calder, P.R. and M.A. Linton. The object-oriented implementation of a document editor. In Object-Oriented Programming Systems, Languages, and Applications Conference Proceedings, pp. 154-165, Vancouver, British Columbia, Canada, October 1992. ACM Press.) To support look-and-feel independence, ET++ uses flyweights. User interface elements or widgets (i.e. scroll bars, buttons, etc.) and their decorations (i.e. shadows, beveling, etc.) are affected by the the look-and-feel standard. A widget delegates all its layout and drawing behavior to a separate Layout object. Layout objects are implemented as flyweights. (Weinand, A., E. Gamma, and R. Marty. ET++--An object-oriented application framework in C++. In Object-Oriented Programming Systems, Languages, and Applications Conference Proceedings, pp. 46-57, San Diego, CA, September 1988. ACM Press.)
Composite, State, and Strategy patterns
Composite pattern, Flyweight pattern, State pattern, Strategy pattern, structural patterns, Gamma patterns, object sharing structure, space efficiency, object (fine-grained)
any system with a large number of objects
costs of managing a large number of objects is highneed to control system resources partly because of object volumeobject identity is not a requirement for a large number of objects
reduced cost of managing objectsshared objects can be used in multiple contexts simultaneously
increased computation time because object state is extrinsic
Test driver Test.javaSimple implementation of the pattern - UnsharedConcreteFlyweight class. UnsharedConcreteFlyweight.javaSimple implementation of the pattern - IntrinsicState class. IntrinsicState.javaSimple implementation of the pattern - FlyweightFactory class. FlyweightFactory.javaSimple implementation of the pattern - Flyweight class. Flyweight.javaSimple implementation of the pattern - ExtrinsicState class. ExtrinsicState.javaSimple implementation of the pattern - ConcreteFlyweight class. ConcreteFlyweight.javaTest driver testflyweight.cppSimple implementation of the pattern. flyweight.h