Flyweight
| Line 1: | Line 1: | ||
The Flyweight pattern is an efficient solution when you need to create large numbers of repeated objects. It is useful when your original design requires that so many objects that represent the exact same things are created at run time that they take up too much memory. An example that [[User:Warwick Irwin|Wal]] gave in class was for his [[Parse tree design|parse tree]], where so many node objects were being created when it was running that it filled up all the memory. Many of the node objects were exactly the same, for example an object to represent an "=" character, however a new object is created every time one is found. The Flyweight pattern provides a way to deal with these repeated objects so that only one of each type is ever stored in memory which is shared among whatever contexts need to use it. | The Flyweight pattern is an efficient solution when you need to create large numbers of repeated objects. It is useful when your original design requires that so many objects that represent the exact same things are created at run time that they take up too much memory. An example that [[User:Warwick Irwin|Wal]] gave in class was for his [[Parse tree design|parse tree]], where so many node objects were being created when it was running that it filled up all the memory. Many of the node objects were exactly the same, for example an object to represent an "=" character, however a new object is created every time one is found. The Flyweight pattern provides a way to deal with these repeated objects so that only one of each type is ever stored in memory which is shared among whatever contexts need to use it. | ||
| + | ==UML Diagram== | ||
The Flyweight pattern structure looks like this: | The Flyweight pattern structure looks like this: | ||
[[Image: Flyweight structure.png]] | [[Image: Flyweight structure.png]] | ||
| + | ==Participating Classes== | ||
| + | ===Flyweight=== | ||
| + | * defines an abstract interface | ||
| + | * concrete objects can either be shared or unshared, it enables sharing but it doesn't enforce it. | ||
| − | Flyweight | + | ===ConcreteFlyweight=== |
| + | * implements the Flyweight interface and adds storage for intrinsic state. | ||
| + | * must be sharable. | ||
| + | * any state it stores must be intrinsic, which means it must be independent of the ConcreteFlyweight object's context. | ||
| − | + | ===UnsharedConcreteFlyweight=== | |
| + | * implements the Flyweight interface and adds storage for all states | ||
| + | * is not shared | ||
| + | * it's common for UnsharedConcreteFlyweight objects to have ConcreteFlyweight objects as children at some level in the flyweight object structure | ||
| − | + | ===FlyweightFactory=== | |
| + | * deals with the Flyweight objects in particular that they are shared properly. When a client requests a flyweight, the FlyweightFactory searches the pool of existing Flyweights and returns the Flyweight if it exists. If it hasn't been created yet, it creates a new Flyweight, adds it to the pool of existing Flyweights, and returns the Flyweight. | ||
| + | |||
| + | |||
| + | As listed above Flyweight objects can either be shared or unshared. It is important to note that the Flyweight pattern merely enables sharing, it does not enforce it. In the [[Parse tree design|parse tree example]], shared objects are for example an "int" type, where there can be many occurrences of the exact same object in various contexts. Unshared objects are for example an ID node that will have a different value field in different contexts, hence these objects cannot be shared. | ||
The design of the Flyweight pattern may not seem like a great design, but is the best way to deal with the efficiency problem described earlier. | The design of the Flyweight pattern may not seem like a great design, but is the best way to deal with the efficiency problem described earlier. | ||
Revision as of 21:50, 6 October 2008
The Flyweight pattern is an efficient solution when you need to create large numbers of repeated objects. It is useful when your original design requires that so many objects that represent the exact same things are created at run time that they take up too much memory. An example that Wal gave in class was for his parse tree, where so many node objects were being created when it was running that it filled up all the memory. Many of the node objects were exactly the same, for example an object to represent an "=" character, however a new object is created every time one is found. The Flyweight pattern provides a way to deal with these repeated objects so that only one of each type is ever stored in memory which is shared among whatever contexts need to use it.
Contents |
UML Diagram
The Flyweight pattern structure looks like this:
Participating Classes
Flyweight
- defines an abstract interface
- concrete objects can either be shared or unshared, it enables sharing but it doesn't enforce it.
ConcreteFlyweight
- implements the Flyweight interface and adds storage for intrinsic state.
- must be sharable.
- any state it stores must be intrinsic, which means it must be independent of the ConcreteFlyweight object's context.
- implements the Flyweight interface and adds storage for all states
- is not shared
- it's common for UnsharedConcreteFlyweight objects to have ConcreteFlyweight objects as children at some level in the flyweight object structure
FlyweightFactory
- deals with the Flyweight objects in particular that they are shared properly. When a client requests a flyweight, the FlyweightFactory searches the pool of existing Flyweights and returns the Flyweight if it exists. If it hasn't been created yet, it creates a new Flyweight, adds it to the pool of existing Flyweights, and returns the Flyweight.
As listed above Flyweight objects can either be shared or unshared. It is important to note that the Flyweight pattern merely enables sharing, it does not enforce it. In the parse tree example, shared objects are for example an "int" type, where there can be many occurrences of the exact same object in various contexts. Unshared objects are for example an ID node that will have a different value field in different contexts, hence these objects cannot be shared.
The design of the Flyweight pattern may not seem like a great design, but is the best way to deal with the efficiency problem described earlier.
