|
-
September 19th, 2005, 01:58 AM
#1
Flyweight pattern
I see the importance of using a pool of distincted objects,
it saves time and space (by not creating instances identical to existing objects).
What I miss here, is the difference between this pattern and maintaining
a std::map.
Please correct me if I'm wrong, but whenever the client of the Flyweight
class has to save the extrinsic state, then for each usage of a Flyweight
(that is shared from the pool) there still stands an object that keeps
the extrinsic state,
which means the pattern seperates the intrinsic (into some structure as map) - but the quantity of objects is decreased only if the extrinsic state
can be computed (but not saved).
**** **** **** **** **/**
-
September 20th, 2005, 06:09 PM
#2
Re: Flyweight pattern
The difference is that std::map is not the Flyweight Pattern itself, but can be used in the implementation of one. Here's an illustration:
http://www.codeproject.com/gen/desig...validators.asp
-
September 21st, 2005, 12:07 AM
#3
Re: Flyweight pattern
 Originally Posted by Darth Hacker
The difference is that std::map is not the Flyweight Pattern itself, but can be used in the implementation of one.
Sure, thats what I meant by "...maintaining a std::map...", which is a good
'tool' to create a pool of distictions.
The Flyweight suppose to reduce the number of objects whenever there
are plenty of objects which most have common states.
That common part is shared from a pool, instead of duplicated for each object.
My question was not about the how to implement the pool (map or other manipulation). I wanted to know whether the main goal of this pattern is the reduction of objects since it seems to me that it saves memory
but whenever the extrinsic state is saved elsewhere - then the number
of objects is not reduced.
**** **** **** **** **/**
-
September 21st, 2005, 10:30 PM
#4
Re: Flyweight pattern
The main goals are to reduce memory usage and possibly to re-use caching.
A word processor can avoid the overhead of having an object for each glyph and still operate with objects by using a simple mapping from character data. The glyphs are completely intrinsic and could cache any aspect of their state, such as their outline.
The colour of the font would be passed into the Draw() function as extrinsic state stored in a text span. Even if extrinsic state is stored on a 1 to 1 basis, you can still get a large degree of memory savings and caching.
-
September 22nd, 2005, 06:05 PM
#5
Re: Flyweight pattern
 Originally Posted by Guysl
My question was not about the how to implement the pool (map or other manipulation). I wanted to know whether the main goal of this pattern is the reduction of objects since it seems to me that it saves memory but whenever the extrinsic state is saved elsewhere - then the number
of objects is not reduced.
That is the goal. It can be done depending on how you are able to save the extrinisic state, as bmoodle's example demonstrates. But it's not always possible. If you are unable to reduce the number of objects, then obviously the Flyweight Pattern doesn't help.
-
September 23rd, 2005, 08:52 AM
#6
Re: Flyweight pattern
 Originally Posted by bmoodie
The main goals are to reduce memory usage and possibly to re-use caching.
Couldn't this be accomplished by using a shared pointer like boost::shared_ptr?
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|