Why are you caching data?
There are multiple reasons to cache data. For example, are you caching because of a performance issue of because of a correctness issue? Know which, and comment it at the spot doing the cache.
If it's performance, the idea is that you have some expensive operation, and you save the results so that you only have to perform the operation once. Sometimes caching can be more expensive than just recreating the object.
If it's correctness, the idea is that you care about object identity. You only want 1 instance of the object floating around. Override operator==, Equals GetHashCode(), etc can mitigate this, but you still have issues. Object.ReferenceEquals will know the difference. And not all .NET languages necessarily map == to operator==. Or maybe you only want the ctor to be called once per object, such if the object owns some exclusive native resource (write access to a file).
There's a maintenance angle from this too.
Two developers may look at the same cache and conclude it was needed for 2 different reasons. This can lead to problems:
- It can also be easy to start taking an unrealized dependency on object identity.
- Somebody may start caching an object without thinking about identity, and so may not go back and add the appropriate Equals() overrides.
- If you assume the cache is for correctness when it's really a performance issue, you may end up doing additional work to maintain the identity that's not needed and impedes performance.
See also:
Clearly Document Object Lifespans.
Object Identity in Managed Debugging