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.
You can implement your own
KeyedCollection
trivially if the extra overhead that comes with the factory settings isn't worth it. The originalKeyedCollection
inSystem.Collections.ObjectModel
is internally aDictionary<TKey, TItem>
and aList<TItem>
which means you can have operations defined on bothIList<>
andIDictionary<>
. For e.g., you can insert, access by index, traverse collection in the inserted order (all whichIList<>
facilitates) and at the same time you can have quick lookups based on key (with the help of dictionary). This means that when you're adding or removing an item they have to be performed on both underlying collections, apart from the small memory overhead to hold the extraList<>
(but the objects are not duplicated as such). Though the addition speeds are not affected much (List<>
addition is O(1)), removal speed is affected a little.If you don't care about insertion order and accessing by index:
I have implemented
ICollection<TItem>
to make it more standard compliant - and also you get the nice collection initializer syntax! :)A sample usage:
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
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.
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.