I'm reviewing my Data access class for the URLyBird 1.2.1 and I've noticed something I'm not sure it is worth worrying about.
I have implemented record caching in the form of a map where the key is the record number, and the value is a String vector
representing the room's data.
The readRecord() simply returns the corresponding String instance object from the cache.
Similarly the updateRecord() and createRecord() change/add the String object into the cache.
As the Data class uses String objects created by the client and exposes String objects belonging to the cache it would be
much safer to make a deep copy of the array before it is returned to the client or put into cache, but this would be an
additional overhead. Otherwise I could rely on the assuption that the client does not change the array's content after having
been passed to/returned from the Data class.
I noticed exactly the same behavior when I was writing my test cases. I didn't make a deep copy, just changed the implementation of my Data class.
If you just adding String (passed as parameter) to my map (and replacing the old record representation), you can change your record cache without using update method:
If you get the String from my map (the record representation), then just iterates over the String (passed as a parameter) and finally update every field you can't update the record anymore without using update method:
That's for the update-method, the create-method you can "fix" in the same way (actually a create is an update on an empty record ;)) The read-method could be fixed with a deep copy, but I didn't do that
Because your are coding the application you can easily make the assumption "the client does not change the array's content after having
been passed to/returned from the Data class". And my business service doesn't use String but uses value objects, so that's a bit of protection, but not a complete one.