tags:

views:

133

answers:

3

I have a Dictionary<int, object> where the int is a property of obj. Is there a better data structure for this? I feel like using a property as the key is redundant.

This Dictionary<int, obj> is a field in a container class that allows for random indexing into the obj values based on an int id number. The simplified (no exception handling) indexer in the container class would look like:

obj this[int id]
{
     get{ return this.myDictionary[id];}
}

where myDictionary is the aforementioned Dictionary<int, obj> holding the objects.

This may be the typical way of quick random access but I wanted to get second opinions.

+5  A: 

There is a KeyedCollection class.

EDIT: The KeyedCollection can use a dictionary internally, but it cleaner interface for this particular scenario than a raw dictionary since you can lookup by values directly. Admittedly I don't find it very useful in general.

Lee
Which uses a dictonary internally anyway...
Paolo
Excellent suggestion. However, if I make my container impliment `KeyedCollection<int, obj>` it exposes a slew of members that I don't want to expose. In particular is the `Clear` method.
Brian Triplett
A: 

C# dynamic properties post seems to show that using a Dictionary was a popular choice. The other posts suggest using a HashTable

Dictionary vs Hashtable

SwDevMan81
+1  A: 

There's no concrete class in the framework that does this. There's an abstract one though, KeyedCollection. You'll have to derive your own class from that one and implement the GetKeyForItem() method. That's pretty easy, just return the value of the property by which you want to index.

That's all you need to do, but do keep an eye on ChangeItemKey(). You have to do something meaningful when the property that you use as the key changes value. Easy enough if you ensure that the property is immutable (only has a getter). But quite awkward when you don't, the object itself now needs to have awareness of it being stored in your collection. If you don't do anything about it (calling ChangeItemKey), the object gets lost in the collection, you can't find it back. Pretty close to a leak.

Note how Dictionary<> side-steps this problem by specifying the key value and the object separately. You may still not be able to find the object back but at least it doesn't get lost by design.

Hans Passant
Excellent suggestion. As I mentioned to @Lee this approach has the unwanted side effect of exposing a bunch of other methods I don't want my class to impliment. The worst of these being the `Clear` method. I need the `KeyedCollection` to be readonly in this case.
Brian Triplett