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 Flyweight Pattern one of the main design patterns. Instead, it should be divided into smaller patterns and considered a Compound Pattern.
The first part of the Flyweight Pattern is breaking an object into pieces. It is sort of like the Strategy Pattern, 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 Extricate Immutable Object? - Steve Metsker]
The second part of the pattern is making the extrinsic part a Value Object. 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 Design Patterns 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??? Answer Me.
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 Flyweight Pattern uses a unique object factory for the flyweight pool. Note that the Singleton Pattern is a special case of the unique object factory pattern.
It sounds like an example of this would be the way a Cee Language or Cee Plus Plus 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 Flyweight Pattern correctly? -- Joshua Juran
Might the first sub-pattern be a specific instance of an Bridge Pattern or State Pattern (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! --Robert Di Falco
How about Externalize Value for the first pattern? I'd use the word "state" except that Value Object seems to clearly be part of the Pattern Language. I think that the third part (Object Per Value?) is an essential part of the Value Object pattern language. In languages where Value Objects Should Be Immutable (like Java Language and Smalltalk Language) 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 Value Objects Can Be Mutable 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 Value Objects and used one of the Factory Patterns to enforce one Object Per Value. -- Phil Goodwin
''A lot of the above discussion seems to overcomplicate things quite a bit.
Q: Isn't Flyweight Pattern 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 Factory Method Pattern, this a Cache Oblivious Algorithm. The user of this class is not aware that the class is a Flyweight Pattern, 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.
See original on c2.com 