Collection<T> class and it's use

Question

I came across the following code:

var collection = new Collection<string>(); 

I haven't seen the Collection class used too much, and can't find too much information about its purpose. Looking at the .NET Framework source, it's pretty much just a wrapper around a List as it stores a List member field. Its constructor is as follows:

public Collection() {   this.items = (IList<T>) new List<T>(); } 

And it also implements IList. So you can declare the Collection as:

IList<string> collection = new Collection<string>(); 

Which to me is functionally equivalent to creating a List instead:

IList<string> collection = new List<string>(); 

So when would you ever want to use it over a List in your own code? I see that it is a base class for other .NET collections, but why would they include this as a public concrete (as opposed to internal and/or abstract)?

---

Regarding comments around possible duplicates -- the answers to related questions seem to say that Collection class is supposed to be used as a base class. What I'm really asking that's different is:

1. If using in your own code, why not use List as a base class instead?
2. Does it really ever make sense to instantiate a new Collection in your own code in place of List?
3. If it really is only provided to serve as a base class, why is it not abstract?

Answer 1

I think the MSDN documentation itself already names the most important aspects (highlights by me):

The Collection class provides protected methods that can be used to customize its behavior when adding and removing items, clearing the collection, or setting the value of an existing item.

and

Notes to Implementers

This base class is provided to make it easier for implementers to create a custom collection. Implementers are encouraged to extend this base class instead of creating their own.

[EDIT for ypur updated questions]

1. If using in your own code, why not use List as a base class instead?

Collection<T> provides some protected methods so you can easily override the behavior and completely enroll your own business logic, like:

• ClearItems()
• InsertItem()
• RemoveItem()
• SetItem()

List<T> does not provide them and has almost no protected methods to overrides behavior, which makes customizing it harder.

2. Does it really ever make sense to initialize a new Collection in your own code in place of List?

No, not just for the sake of initializing some collection. Use it if you need it as a base class for implementing your own logic.

This will depend on your own business needs. For almost all cases in daily development work, the existing - and numerous - collections should already provide what you need. There are type safe and untyped collections, thread-safe collections, and whatever else you can think of.

Still, one day there may be a demand for implementing a collection type that does certain valididation checks before it allows to add/update/delete any items in it or that handles moving to the next item in a only sparsely populated list in a specail manner. You never know what ideas a customer may have.

In those case it might help to create your own collection type.

Answer 2

The Collection(T) class is the base class for a whole bunch of other collection classes. The List class, is a class that is optimized for speed, and the Collection class, is designed for extensibility.

When you look at the members of Collection(T), you'll see that it contains some additional protected virtual methods (like InsertItem) that the List(T) class doesn't have.

In fact, I've created an instance of the Collection class. I think I would only use this type as a parameter in a method signature, just to not tightly couple the method with the implementation of the collection (if possible).

To answer your questions:

1. I would use Collection(T) as a base class, because it's the intention of that class to be used as a base class for other collection types. It offers you more flexibility (see the protected virtual methods InsertItem, RemoveItem and SetItem)

2. When in need of a collection, I would use an instance of the List(T) class, since it is optimized for speed.

3. Actually, I wonder why they haven't made the Collection(T) class abstract.