Flyweight Pattern Discussion

Flyweight is a fairly complex pattern with several parts. Many designs that are said to use Flyweight have only a few of those parts. In fact, a full Flyweight is fairly rare. So, I have started to think that it was a mistake to make the FlyweightPattern one of the main design patterns. Instead, it should be divided into smaller patterns and considered a CompoundPattern.

The first part of the FlyweightPattern is breaking an object into pieces. It is sort of like the StrategyPattern, where the original object is broken into the strategy and the context, and the context has to be passed into the strategy for the strategy to work. A flyweight is broken into an intrinsic part and the extrinsic part. The extrinsic part is going to be passed into the intrinsic part. I can't think of a good name for this pattern. Maybe "breaking objects into pieces?" Yuck! [How about ExtricateImmutableObject? - SteveMetsker]

The second part of the pattern is making the extrinsic part a ValueObject. In other words, you have to get rid of any side effects on it. When you do that, you can share all similar extrinsic parts. But you need a way to find when a new extrinsic part is the same as an existing one. You seem to be using intrinsic and extrinsic here in the opposite sense from that used in the DesignPatterns book. Is that intentional?

I think quite the opposite is true: You want to save whole objects instead, but if they are immutable, so that for example in Smalltalk all those character objects do not use so much space (there would be at most 256 for example).
In case that objects are mutable, then they should be serializable and those serializations should be stored in a cache. I wonder if that would use less memory??? AnswerMe.

This is done by the third part of flyweight, a "unique object factory". You create an object by asking a factory for it and giving parameters to describe it. If the object already exists, the factory just returns it. Otherwise, the factory creates the object. The FlyweightPattern uses a unique object factory for the flyweight pool. Note that the SingletonPattern is a special case of the unique object factory pattern.

-RalphJohnson

It sounds like an example of this would be the way a CeeLanguage or CeePlusPlus compiler deals with static string constants -- duplicate occurrences of the same string in the source code get merged into a single instance in the executable. Do I understand the FlyweightPattern correctly? -- JoshuaJuran

Might the first sub-pattern be a specific instance of an BridgePattern or StatePattern (rather than implementing state as a flyweight)? Maybe a SectionedBridgePattern, where the outer class only encapsulates one part of the implementation (i.e. context) object. The Context seems to work like an encapsulated state. Actually, I'm less confident about it now than when I first started typing this entry! --RobertDiFalco

How about ExternalizeValue? for the first pattern? I'd use the word "state" except that ValueObject seems to clearly be part of the PatternLanguage. I think that the third part (ObjectPerValue??) is an essential part of the ValueObject pattern language. In languages where ValueObjectsShouldBeImmutable (like JavaLanguage and SmalltalkLanguage) the ability to combine object identity with object state can produce a huge savings in the space and time that a program uses. It also makes it easier to write code correctly because there is no need to remember when to compare identities and when to compare state. Of course if you're using a language like C++ then ValueObjectsCanBeMutable and there's no confusion about the difference between identity and state, but you'd still see a boost in performance and simplicity if you used immutable ValueObjects and used one of the FactoryPatterns to enforce one ObjectPerValue?. -- PhilGoodwin

''A lot of the above discussion seems to overcomplicate things quite a bit.

Q: Isn't FlyweightPattern simply an extra layer of indirection?

We do this kind of thing all the time in videogames development. And I would think any programmer worth his salt uses this strategy over and over, over the course of normal work, no matter the industry. It's all about eliminating redundancy (that you'd have to maintain in parallel), and increasing flexibility and power by introducing a layer of indirection).

A: Yes, it is an extra layer of indirection and also it is a cache. When combined with the FactoryMethodPattern, this a CacheObliviousAlgorithm?. The user of this class is not aware that the class is a FlyweightPattern, but it uses less memory while providing all the object oriented benefits.

Q: Am I missing something here?

A: I think not. Most design patterns are obvious once you understand them. Before that moment, they are kind of cumbersome to grasp, specially if you are not used to thinking and expressing yourself in terms of patterns.

CategoryDiscussion CategoryPattern