Collection Classes, Generics and C# 2

[Guest]

Can someone explain a few things about collections to me.

In C# 2 generics, you can create a collection class by inheriting from
System.Collections.ObjectModel.Collection. Using this you can iterate through
the collection and use "foreach" on the collection.

public class Cars : System.Collections.ObjectModel.Collection<Car> { }

So, could someone explain to me why you would want to create a GENERIC
custom collection class.

See http://www.codeproject.com/dotnet/GenericCustomClass.asp -- "Writing
Custom Collection Classes" section

I haven't really used collection classes or had to write one for .Net 1.1,
so i am a little perplexed.

Many thanks, CR

 

[Marc Gravell]

Well, as a thought, you might want to abstract the implementation from
the public API - especially if your code is being consumed by external
parties. That way, you can change the internals without breaking the
clients - for instance, switching to a dictionary of some kind.

This is also necessary if the base container is sealed (or doesn't
provide many virtuals), and you want to customize the behaviour - i.e.
extra methods (can't do if sealed) or extra checks (can't do if not
virtual). You can also limit the methods available - perhaps Clear()
isn't sensible for your scenario?

Marc

 

[Guest]

thanks marc,

so for the most part, using the System.Collections.ObjectModel.Collection
will be good enough.

 

[Jon Skeet [C# MVP]]

so for the most part, using the System.Collections.ObjectModel.Collection
will be good enough.

Well, unless you need to add extra functionality, I'd normally use the
collections in System.Collections.Generic, personally.

Jon

 

[Marc Gravell]

I've looked at the article... the author has a generic collection
inheriting from CollectionBase - so isn't exactly good gode to follow
;-p Plus a good half-dozen other glaring mistakes... (new ToString(),
GENERICTYPE vs GenericType [won't build], Item[int] instead of
this[int], etc - plus common style/naming conventions). IMHO, not a
good article.

Stick to Collection<T> or List<T> and you'll be fine. When you need
something more complex, you'll know ;-p

Marc

 

[Fred Mellender]

Note that you do not need to inherit from Collection in order to implement
the "foreach" construct. Just write a method that returns IEnumerable<T>,
as in

public IEnumerable<T> Astar()

{

}

which I implemented in a class called Graph.

This allows you to use the "yield return" construct (in Astar) so that
callers can invoke the "foreach" function on the method, as in

foreach (KSnode ksn in graph.Astar())

{

}

This makes Astar look like a collection to your users, without your needing
to inherit from collection (or even making use of List<T>, etc).

For other examples of using generics in combination with the "foreach"
construct, in order to implement collection-like behavior, see
http://www.frontiernet.net/~fredm/dps/Contents.htm .

 

[Samuel R. Neff]

The advantage of generics is that you generally don't need custom
collection classes any more. In .NET 1.1 people used to create custom
collections so that they could enforce a constraint on the type of the
contents of the collection. With Generics in .NET 2.0 you no longer
need a custom class for this.

Most of the time you'll just use List<T> or Dictionary<TKey, TValue>
directly instead of creating a custom collection.

The exception is when you need different behavior. That is a far
rarer situation than simply different contents. One example of
different behavior from my current application is a custom KeySet<T>
collection. This is basically a dictionary without a value, just keys
as I've found myself often needing to use a dictionary to store a
unique set of keys and checking existence in the collection without
caring about any actual value. Implementing this as a custom generic
class made usage of the class cleaner than when using
IDictionary<T,T>.

HTH,

Sam

 

[Guest]

thanks for your help.
it was useful.