Michael Marcin escribió:
The flyweight factory concept seems to be missing a key part of the GoF Flyweight pattern's FlyweightFactory participant. The GoF factory supplies the flyweight if one exists. This is what the current boost flyweight Factory concept does. If no flyweight exists the GoF flyweight factory creates one. In the boost flyweight library this functionality is somewhere else that doesn't seem to be described in the documentation.
The name factory for what is currently in place is misleading. Isn't it really just an associative container?
Well, this terminology issue has been raised before and I finally decided to stick with "factory" for lack of a more descriptive name. It is not an associative container, though in most cases factories are built on top of associative containers. I hope the important thing is that the reader gets a clear understanding of what these factories do in the context of Boost.Flyweight.
I'm trying to use flyweight to represent texture objects right now. These are surely a good candidate for use with flyweight as they are one of the examples given. My textures are fairly simple objects, with low coupling. Creating a texture is however expensive and has a lot of dependencies (libjpeg,libpng,etc). I typically have a TextureFactory which decouples the construction of a texture from the actual texture object and allows the work required to setup the various libraries to read images to be reused by all textures constructed from the same TextureFactory instance.
It doesn't seem possible to have this decoupling with flyweight. Am I missing something?
Not sure if this is what you're after, but have you consulted the section on key-value flyweights? http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/doc/tutorial... Does this approach your use case? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo