I am currently researching software design patterns and have been somewhat perplexed with the flyweight design pattern's implementation.
As far as I understand, the pattern works by separating the shared/constant intrinsic data from the unique, changing extrinsic data. The intrinsic data is kept in a set of objects that are managed by a factory class to prevent duplicate intrinsic data objects. This I understand.
What I don't get is what I do with the extrinsic data. In the examples I've seen which have mostly been about drawing shapes for some reason, the extrinsic data is just brought up to a higher level where it is passed into a method in the intrinsic object. Is this always the case or is this just a result of everyone using the shapes example?
One thought I had is to use composition to add a reference to the intrinsic object into an object with the extrinsic data. The only additional space in the object is the size of the reference. Would this work as a good example of the flyweight design pattern?
Thanks!
One thought I had is to use composition to add a reference to the intrinsic object into an object with the extrinsic data.
The object responsible for extrinsic data is called the Client in the Flyweight pattern. The Client calls a FlyweightFactory to acquire a Flyweight instance and store a reference to that instance; so this is exactly the composition relationship you're referring to.
In modern code, the Client may be instantiated by a Dependency Injection framework, which replaces the FlyweightFactory; but that's an implementation detail.
I think the bigger difference is that most developers would not pass the extrinsicState into the Flyweight, but would rather have the Client read the intrinsicState. This is a more procedural and less OO approach, which treats the intrinsicState as a dumb data structure rather than a first-class object with both state and behavior.
I would probably favor that approach myself, as caching data is more intuitive to me than caching objects.