System.Collections vs. System.Collection.Generic and System.Collections.ObjectModel

Many people ask how the new.NET Framework 2.0 generic collections relate to the non-generic collections we shipped before. So, here you go. The most important types are in bold font.

List<T> is basically a better ArrayList. It is optimized for speed, size, and power. Use it for majority of internal implementations whenever you need to store items in a container. Do not use it in public APIs.

Dictionary<TKey,TValue> is just a strongly typed Hashtable. Some changes were made to the hashing algorithm. The details are described here.

Collection<T> is a much better CollectionBase. Use it to expose read/write collection output from public APIs. It’s in System.Collections.ObjectModel namespace. Why in a separate namespace and why such strange name? See here.

ReadOnlyCollection<T> is a much better ReadOnlyCollectionBase. It’s in System.Collections.ObjectModel namespace.

Queue<T> and Stack<T> are equivalent to Queue and Stack.

SortedList<TKey,TValue> is basically a generic version of SortedList.

SortedDictionary<TKey,TValue> does not have a corresponding non-generic collection. It’s similar to SortedList and SortedList<TKey,TValue>, but it’s implemented as a balanced tree (red-black tree). Insertions are on average much faster, but some lookups are slightly slower and memory consumption is larger.

IEnumerable<T> is just like IEnumerable, but strongly typed. One difference is that IEnumerable<T> extends IDisposable. The reasons are described here.

ICollection<T> seems like ICollection, but it’s actually a very different abstraction. We found that ICollection was not very useful. At the same time, we did not have an abstraction that represented an read/write non-indexed collection. ICollection<T> is such abstraction and you could say that ICollection does not have an exact corresponding peer in the generic world; IEnumerable<T> is the closest.

IList<T> is just strongly typed IList. We removed the notion of IsFixedSize and the reasons are described here.

IDictionary<TKey,TValue> is roughly equivalent to IDictionary.

DictionaryBase does not have a corresponding generic type. Simply implement IDictionary<TKey,TValue> if you need a custom dictionary.

Also, we added KeyedCollection<TKey,TItem>. It’s a new collection which allows items to be indexed by both a key and an index. Use it to expose collections of items that have natural “names” (keys) from public APIs. You need to inherit from the collection to use it.

And finally many people asked for linked-list. LinkedList<T> was added to .NET Framework 2.0.

So here is the summary:

Non-Generic Similar Generic Type
ArrayList List<T>
Hashtable Dictionary<TKey,TValue>
SortedList SortedList<TKey,TValue>
Queue Queue<T>
Stack Stack<T>
IEnumerable IEnumerable<T>
ICollection N/A (use IEnumerable<T> anything that extends it)
N/A ICollection<T>
IList IList<T>
CollectionBase Collection<T>
ReadOnlyCollectionBase ReadOnlyCollection<T>
DictionaryBase N/A (just implement IDictionary<TKey,TValue>
N/A SortedDictionary<TKey,TValue>
N/A KeyedCollection<TKey,TItem>
N/A LinkedList<T>

Let me know if you would like me to blog more information about any of these types.

Comments

• Anonymous
  September 23, 2005
  Thanks for the summary - very informative.
  
  Why do you recommend to not use List<T> in public APIs?

• Anonymous
  September 24, 2005
  So in a public API that you are shipping, you want to use Collection<T> by deriving from it, correct?
  
  What about if you are not developing an API, but a layered app and you are exposing classes/collections from a Common assembly through a BL layer...is it OK to use List<T> or should you derive from List<T> and always return the derived class? I kinda like being able to return List<T>. Thoughts?

• Anonymous
  September 25, 2005
  Krzysztof, I'm curious to know why you shouldn't publically expose List<T>.
  
  Thanks

• Anonymous
  September 26, 2005
  I just posted the reasons why we don't recommend List<T> in public APIs. See http://blogs.msdn.com/kcwalina/archive/2005/09/26/474010.aspx
  
  Sean, using List<T> in app shared libraries may be fine as long as you can and are willing to make some breaking changes to the libraries when you discover that you need change the behavior of the collection and the only way to do it is to change it to Collection<T> and override some members. Such changes are often possible in libraries that are not distributed widely.

• Anonymous
  March 29, 2006
  The comment has been removed

• Anonymous
  March 30, 2006
  Philip, I understand your question is about the collections in System.Collections.Generic namespace. The answer is that such virtual methods make would make the collections slower. To enable the exact scenario you are asking about, we added the System.Collections.ObjectModel namespace. Collections in this namespace do have virtual protected methods which you can use to get notified when an item is added or removed.

• Anonymous
  August 10, 2006
  The comment has been removed

• Anonymous
  September 06, 2006
  Great post -- I look this up all the time :)
  What do you say that ICollection has no generic equivalent (or, at least, you suggest using IEnumerable<> instead of ICollection<>)?

• Anonymous
  September 07, 2006
  ICollection is immutable (no members to change the contents of the collection). ICollection<T> is mutable. This is a substantial difference making the interfaces similar only in their name. One the other hand ICollection and IEnumerable<T> differ by very little.

• Anonymous
  September 26, 2006
  On utilise tous les jours les interfaces IEnumerable, ICollection, IList quand on d&#233;veloppe en .Net,...

• Anonymous
  October 22, 2006
  On utilise tous les jours les interfaces IEnumerable, ICollection, IList quand on développe en .Net,

• Anonymous
  March 05, 2007
  I am using CollectionBae as below. How can I use generics instead? public class ItemCollection : CollectionBase { public ItemCollection.ItemInfo this[ int index ] { get { return (ItemCollection.ItemInfo)List[ index ]; } set { List[ index ] = value; } }

• Anonymous
  March 05, 2007
  Nital, You can use Collection<ItemInfo> instead of your subclass of CollectionBase.

• Anonymous
  March 18, 2007
  hi Krzysztof, nice post. Thanks. Regards, Alessandro

• Anonymous
  June 19, 2007
  Excelent solution!... a friend did some workaround trying to create this class!!... Good things about frameworks=a lot of stuff already done!, Bad thing=you should know where it is happyCoding

• Anonymous
  January 06, 2008
  Speed Test: Generic List vs. ArrayList

• Anonymous
  January 17, 2008
  Why do Generics provide little to no speed-up over non-Generics, and are also at least 2x slower then running the same code (without Generics) in .NET 1.1? I'm talking about a program that stores database information in Hashtables. One of these hashes strings to ArrayLists and there are around 10,000 key, value pairs. The other hashtables are similar in size.

• Anonymous
  February 03, 2008
  Speed Test: Generic List vs. ArrayList

• Anonymous
  March 13, 2008
  ref:http://blogs.msdn.com/kcwalina/archive/2005/09/23/Collections.aspxPublished23September0508...

• Anonymous
  June 28, 2008
  （准确的说是.Net的。但我只对C#比较熟，像VB.Net之类的还有自己以前的一些集合类带过来暂不考虑。下面以.Net2.0的BCL为准，至少它们到3.5都没大变化。） Reference...

• Anonymous
  June 30, 2008
  Anybody knows why below is not working??? BO2 inherits from BO and M1 shall accept this collection as well. Doesnt it? public class BO {} public class BO2 :BO {} public class BOC <BO> : BindingList<BO>  {} public class Client { public void M1 (BOC <BO> BOCollection) { } public void M2 () { M1( new BOC<BO2>() ); } }

• Anonymous
  January 23, 2009
  MCTS self-paced exam book lists SortedDictionary as non-generic counterpart of Generic SortedDictionary class. This is not true as I searched the objects under Object Browser in VS 2005 and also you mentioned N/A against its non-generic class. So this blog is very informative and helps.

• Anonymous
  September 10, 2011
  thanks sir my knowledge got deeper after reading the theory