Implementing a Tag property on entity classes

Question

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.

Answer 1

You could extend IDictionary or Dictionary to make it mutable. However something tells me that you're probably going about this wrong in general. Loosely typed collections are always fun on the delivery end...

That's just my 2c, kind of subjective, but I avoid loose types unless they're necessary.

Answer 2

Something like this maybe?

public class Taggable :ITaggable
    {
        private IDictionary<string, object> _tags = new Dictionary<string, object>();
        public void AddTag(string key, object tag)
        {
            _tags.Add(key,tag);
        }

        public bool IsTag(string key)
        {
            return _tags.ContainsKey(key);
        }

        public T GetTag<T>(string key)
        {
            return (T) _tags[key];
        }
        public void RemoveTag(string key)
        {
            _tags.Remove(key);
        }
    }

Although I have not included it, all four methods are on the interface.

No one can 'abuse' the collection as they would need to know the key.

Answer 3

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:

private Dictionary<Entity, object> myPrivateEntityData = new ...;

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.

private Dictionary<Entity, SuperSecretSpecialData> myPrivateEntityData = new ...;

private sealed class SuperSecretData {
    public bool     NoOne;
    public int      ElseBut;
    public string   MeCan;
    public DateTime SeeThis;
}

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 AutoDictionary which simply extends Dictionary in such a way that it automatically creates objects when they are missing:

public sealed class AutoDictionary<TKey, TVal> : Dictionary<TKey, TVal> where TVal : class, new()
{
    public new TVal this[TKey key]
    {
        get
        {
            if (!ContainsKey(key))
                Add(key, new TVal());
            return base[key];
        }
        set
        {
            base[key] = value;
        }
    }
}

private AutoDictionary<Entity, SuperSecretSpecialData> myPrivateEntityData = new ...;

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 use ContainsKey if you want to check if it’s there.