I've never used any of the .NET generics in my work, but I understand that they are fairly popular. Does anyone have any good links or book suggestions for learning them? As a bonus; I only vaguely understand what .NET generic collections are and what they do...does anyone have any practical examples of how they might be used to greater advantage than the normal collections in .NET?
CLR via C# by Jeffrey Richter goes into depth about generics, and is one of the priceless resources every .NET developer should own and read.
If you've ever used C++ templates, then .Net generics are nearly the same thing. They even use a similar <T> syntax.
Even if you don't know any C++ you're probably making this harder than you need to, especially with regard to the collections. They're just like any other collection, but when you create them you supply a type name inside the <<>'s so the compiler knows what kind of item they hold.
C# 3.0 in a Nutshell is a fantastic reference book with examples just big enought to grasp the concept without feeling bloated.
My vote is- mostly you can just avoid them :)
The main advantage for generics is to save casting, if you end up doing casting internally that doesn't make any sense. If you try to look into this issue you would found that mostly the candidates for generics are really those collections/sets which could create native storage internally for such benefit. Most other components, on the other hand, gain little/no performance, and degrades the flexibility significantly comparing to an interface inheritance implementation.
If casting annoys you so much, maybe time for you to consider dynamic languages like IronPython :)
And- if you really come across a scenario you think generic make sense, post it out as another question, the brains here could look together and solve it case by case :)
Update: Yep compiler checking is nice, but check Castle Project's source, you can see many situations where a generic type gets into the way because you can't do casting- making things like IBusinessObject is a lot more flexible than BusinessObject- because you can't cast something inherit from BusinessObject back to BusinessObject and expects to access a function inherited. Usually I saw code end up as BusinessObjectBase -> BusinessObject ->Your actual class. That's why I kinda feel its not always beneficial to use generics- and I was one of those who did abuse such implementation and end up having tons of funny function with generic typing, not nice at all.
Update #2: Boxing/Unboxing just means the requirement to cast the object when you use an abstract type (like object) to store value and use a strong typed value to store it back again (which requires casting), not much difference I can see apart from the collection situation I stated. AND code like this still does boxing:
public T GetValue<T>() {
return (T) ...;
}
Thats the generic abuse I have seen most often. People think they are dealing with native type here, in fact they are not. Instead they just make the casting into generic syntax. What really make sense is this:
public class MyList<T>
{
private List<T> _list;
...
public T GetValue(int index)
{
return _list[index];
}
Then thats again back to our collection storage. Thats why I said after collection storage I don't see a lot of chance generic helps. Referred from this tutorial: http://en.csharp-online.net/Understanding_Generics—Revisiting_Boxing_and_Unboxing
I found WROX's Professional .NET 2.0 Generics very useful as it contains lots of real world examples. Generics could be confusing to the beginner but they could be a very useful/powerful/time saving tool in the hands of an experienced developer. Personally, I find .NET Generics most useful in simplifying the defining and use of collections. Also the use of generics could lead to more efficient code as it could minimize the performance hit usually associated with boxing/unboxing type conversions.
It's best to follow some Microsoft training on the subject. If you are looking for books, the following would be ideal:
dear goodwill, you don't get neither polymorphism nor generics nor Liskov Substitution Principle.
You can create an object of List>