0

Classic Flyweight pattern implementation example from GoF book only stores character code in sharable "Characters" and uses "GlyphContext" to store extrinsic state in a tree structure. This example also mentions Rows and Columns, however it doesn't mention how would one store a "collection" of flyweights ("Character" objects).

It's clear that this pattern allows to avoid creating huge number of objects by sharing instances, but how can one create a structure of such objects (for example, to represent a document) without creating a structure of references to cached objects (which would invalidate the purpose of the pattern)? I see that other examples use cached instances as "throw-away" objects, without building any sort of structure, but this doesn't seem to make any sense, since it could be replaced by a set of static operations.

Is it correct to conclude that if one needs to refer to flyweights after they are created, the benefit of the pattern can roughly be calculated as [size of intrinsic state]/[size of object reference]. This means that flyweight with only 1 field doesn't make sense?

EDIT: I was wrong in my "memory calculations"... Without flyweights, you need to store references anyway, but with flyweights, you don't need to store objects anymore. The basic point of the question still seems to be valid - the extent of savings, provided by the pattern is proportional to the size of intrinsic state, not the number of "logical objects". True or false?

Konstantin
  • 3,817
  • 4
  • 29
  • 39
  • Have I missed the point? A Character in the GoF sense would hold more information than just the (unicode) character - it could hold information about size, variants, etc... that you wouldn't want to be duplicated. – kͩeͣmͮpͥ ͩ Apr 07 '11 at 14:47
  • @David, that would make sense. That would probably also confirm correctness of my conclusion (last sentence of the question)? – Konstantin Apr 07 '11 at 14:58

1 Answers1

0

Yes, even one field flyweight object makes sense if you will use that object a lot. Its faster to get their instances, then making new objects.

I find Map <string name, Object yourobject> (in Java) a good way to store them. Why you need "no structure"?

Using some structure to store flywieght being in use doesn't invalidate the purpose of the pattern. You need some instances of flywieghts to use them. You can make them during runtime and add them to list of them (that's the way it should be done, to avoid unneeded objects), or you can prepare them before runtime (witch makes "low" sense).

dantuch
  • 9,123
  • 6
  • 45
  • 68