I read about Flyweight design pattern and got to know that it stores the objects that can be shared so as to save on heap usage. Java cache also saves the objects that can be reused later so as to save memory. Then what is the real difference between Flyweight design pattern and java cache ?
Flyweight is a structural design pattern that allows programs to support vast quantities of objects by keeping their memory consumption low. The pattern achieves it by sharing parts of object state between multiple objects. In other words, the Flyweight saves RAM by caching the same data used by different objects.
Flyweight pattern is primarily used to reduce the number of objects created and to decrease memory footprint and increase performance. This type of design pattern comes under structural pattern as this pattern provides ways to decrease object count thus improving the object structure of application.
Flyweight is a structural design pattern that lets you fit more objects into the available amount of RAM by sharing common parts of state between multiple objects instead of keeping all of the data in each object.
String class is designed with Flyweight design pattern. It has similar structure as above example. When you create a string constant, such constant is stored in a pool.
The Flyweight design is usually a store of immutable objects.
A "Java cache" is not a well defined term. It can mean many things such as a results cache, or a resource object pool.
Let's assume "Java cache" is an object pool (or object pool pattern).
I think the difference lies in the understanding of objects being cached are singleton or not.
In the flyweight pattern, you use the same object fetched from "the factory" by potentially multiple clients. That requires different way of managing stuff (like concurrency, client-related work etc.). For example, if you fetch the same flyweight object (let's say a button) in multiple UI clients/viewports which are visible at the same time, then you end up with manipulating the same object (for example the button text) which may create inconsistency on these different UIs/viewports. That won't happen since the pool/cache will return you a separate object each time you ask for an object.
Regarding being immutable, I've encountered couple of examples on the web which includes extrinsic/changing state in the flyweight object. Well, I don't think it's completely wrong to include it as a part of a flyweight object, since the point is reducing the memory footprint, as long as you can manage objects properly. But I also think that it's totally open to discussion.
Flyweight pattern is a structural design pattern - something which impacts the structural design of your objects. The key points in this design pattern is shareable and non-shareable state. The shareable state is stored in the Flyweight objects (since it is context independent). There might be extrinsic state as well which is not shareable and the burden of specifying that state falls on the client as that is context specific.
Now you can use caching to implement Flyweight pattern but caching in general has nothing to do with Flyweight pattern as such. The idea of caching has larger context in that it is beneficial for saving your computing resources (CPU/Memory/Network) by virtue of reuse.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With