[ACCEPTED]-Collection<T> class and it's use-collections

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

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

and 25

Notes to Implementers

This base class is 24 provided to make it easier for implementers 23 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 22 some protected methods so you can easily 21 override the behavior and completely enroll your 20 own business logic, like:

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

List<T> does not provide 19 them and has almost no protected methods 18 to overrides behavior, which makes customizing 17 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 16 some collection. Use it if you need it as a base class for implementing your own logic.

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

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

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

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

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

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

To answer your questions:

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

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

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

As Krzysztof Cwalina puts it:

•List is not designed 24 to be extended. i.e. you cannot override 23 any members. This for example means that 22 an object returning List from a property 21 won’t be able to get notified when the collection 20 is modified. Collection lets you overrides 19 SetItem protected member to get “notified” when 18 a new items is added or an existing item 17 is changed.

•List has lots of members that 16 are not relevant in many scenarios. We say 15 that List is too “busy” for public object 14 models. Imagine ListView.Items property 13 returning List with all its richness. Now, look 12 at the actual ListView.Items return type; it’s 11 way simpler and similar to Collection or 10 ReadOnlyCollection.

For this reason, FxCop's 9 rule CA1002 also tells you not to expose 8 generic Lists and use Collection instead. See 7 also this Code Analysis Team Blog post about the FxCop rule and why 6 to return Collection rather than List.

So 5 for question 1 and 2, see above. As for 4 question three, it's not just there to serve 3 as a base class. You're supposed to be able 2 to instantiate it and use it as a return 1 type as well, hence it's not abstract.

I don't really like answering my own questions, but 11 as far as Q3 is concerned I believe I understand 10 the reasoning. I got it while looking at 9 this link referenced in Bas Paap's answer.

In short, the 8 reason the Collection class is not abstract 7 is because you may want to leave yourself 6 the option of deriving from the class at 5 a later date. In the meantime, you can use 4 it as a return type and instantiate it directly. The link shows 3 a code example where this is the case.

I've 2 upvoted all other answers that I thought 1 addressed the issues raised in the question.

Although the enumeration interfaces provides 14 a forward-only iteration over a collection, they 13 do not provide a mechanism to determin the 12 size of a collection, access a member by 11 index, search, or modify the collection. For 10 such functionality, the framework provides 9 the ICollection, IList and IDictionary interfaces.

ICollection<T> provides medium 8 functionality (for example the Count property).

IList<T> and 7 their non-generic version provide maximum 6 functionality (including 'random' access 5 by index).

It is rare that you will need 4 to implement any of these interfaces. In almost all 3 cases when you need to write a collection 2 class, you can instead subclass Collection<T> etc.

I hope 1 this helps.