Forums Register Login

Read-only objects in cache

+Pie Number of slices to send: Send
Hi guys,

I'd like a bit of a sanity check and some help.

We have an object that's reasonably big and expensive to construct (processing and database usage). This object basically provides a structure for the system to work - the objects are referenced to perform operations, but never changed.

So, this expensive object can be cached and shared between all users as it should not be changed by any user operation.

So my question is: is there a way to ensure the application only reads from this object (and it's sub-object arrays), but never changes the object or any of it's sub-objects?

Basically, I need to create a read-only version of the object (and it's arraylists of objects).

Any help is much appreciated on how best to achieve this?

Cheers,

Steve
+Pie Number of slices to send: Send
Make the object immutable (think of String as an example).
+Pie Number of slices to send: Send
Making the structure final ought to be sufficient.
+Pie Number of slices to send: Send
But if the object has public variables or setter methods, then it isn't read-only. I'd recommend that the class:

be declared final
have no setters
be tightly encapsulated
+Pie Number of slices to send: Send
>is there a way to ensure the application only reads from this object (and >it's sub-object arrays), but never changes the object or any of it's >sub-objects?

Arrays? Don't expose your data structure's original arrays because arrays are never "read only":


>Basically, I need to create a read-only version of the object (and it's arraylists of objects).

Check out java.util.Collections' unmodifiableList method.
+Pie Number of slices to send: Send
 

Originally posted by Roger Chung-Wee:
But if the object has public variables or setter methods, then it isn't read-only.


I feel like I missed something. Was there a suggestion that the structure in question have either of these things?
+Pie Number of slices to send: Send
Steve wants his application to only read from this object (and it's sub-object arrays), but never change the object or sub-objects. So, one of the things that the developer needs to do is ensure that a client cannot change the object's variables. Hence my recommendation that the class be immutable.

Jeff has made a good point that any mutable objects referenced by private variables need to be defensively copied in the getters. I think that a class written like this should be as close to read-only as possible.
Look ma! I'm selling my stuff!
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 941 times.
Similar Threads
Lazy Loading
When are Threads garbage collected?
Caching objects in a session
Listening for a state change of a POJO
subclass in sequence diagram
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 18:47:48.