When I create entities in a class library, I tend to add a Tag property which may be used by users and extending libraries to store arbitrary data with the object. Now I am looking for the best way to implement such a Tag property in my class library, and the reasons why.
In System.Windows.Forms, Microsoft uses object Tag { get; set; } as the signature, but it looks too limiting as only one may use the Tag at any time.
I also thought about HashTable Tag { get; } to allow anyone to set and retrieve any data by key, but it seems too ‘exposing’ for a class library. Then IDictionary Tag { get; } would be a better option, but both allow anyone to clear the entire dictionary which I want to avoid. Then again, both HashTable and IDictionary only allow you to work with object instances, where something generic may be a better choice. But Dictionary<?> Tag { get; } is obviously not going to work for all possible consumers.
So, which way to go?
Edit:
As Timwi below correctly suggested, I don’t want different user classes to be able to interfere with eachother. I assume a scenario where there are many entity classes and only a few classes which want to store associated data.
It appears that one of your requirements is that the individual threads or processes that access an entity object should not be able to see each other’s private data. I’m afraid this is a pretty good indication that the private data should not be in the entity object which is shared by them. Instead, each process should have its own private data. It doesn’t have to be actually in the entity object itself, but it can be associated with the entity object via a private dictionary:
Furthermore, since this is now private to the process, and the process presumably knows exactly what kind of data it wants to associate with each Entity, you can now make it completely typesafe.
There is some pain associated with having to check whether each entity is in the dictionary first, but you can fix this too. Personally I use a class
AutoDictionarywhich simply extendsDictionaryin such a way that it automatically creates objects when they are missing:Then you can easily access
myPrivateEntityData[someEntity].NoOne(etc.) and it will just work and never throw an exception because the key is not there, and yet you can still useContainsKeyif you want to check if it’s there.