Why not always use Generics?

Question

I am reading existing posts on Generics at SO. If Generics has so many advantages like Type safety, no overhead of boxing/unboxing and it is fast, why not always use it. Why to go for a non-generic thing?

Edited (Question further extended below)

I am a bit confused. The last time I read about Generics, months back, I read that if the Type in the parameters is not sure, Generic should be used to prevent error.

But what I read now, it says that Generic limits to a fixed Type. A non-generic thing allows to define parameter type at run-time.

Please correct me.

Secondly, these things like OOP, Generics etc. are helpful when you are working in a team and your code is shareable. For a lone programmer, who knows what Type has to come in the parameter, I guess there is no need to worry, whether it is Generic or Non-Generic.

Answer 1

You should use generics. Much of the code in the .NET framework that doesn't use generics but should was written before generics was introduced in .NET 2.0. If that code were rewritten today it probably would use generics.

Of course you do not want to use generics when you know the specific types involved. Not everything should be made generic.

Answer 2

In general you should - however, there are times (especially when writing library code) when it is not possible (or certainly not convenient) to know about the calling type (even in terms of T), so non-generic types (mainly interfaces such as IList, IEnumerable) are very useful. Data-binding is a good example of this. Indeed, anything that involves reflection is generally made much harder by using generics, and since (via the nature of reflection) you've already lost those benefits, you may as well just drop to non-generic code. Reflection and generics are not very good friends at all.

Answer 3

Generics may be fast and type safe, but also add complexity (another dimension which can vary and must be understood by programmers). Who is going to maintain your code? Not every trick with generics (or lambdas, or dependency injection, or...) is worth it. Think about what problem you are going to solve, and what parts of that problem may change in the future. Design for those cases. The optimally flexible software is too complex to be maintained by mortal programmers.

Answer 4

Sometimes "object" collections are simply unavoidable. Often this happens when there's multiple types in the same control/collection - the only type they have in common is "object", and so that's the best type for your collection.

Another case for object (non collection related) that pops up from time to time can be seen with the PropertyGrid. A third party property grid may allow you to attach a "validator" which returns whether the users new value for a given property on the grid is acceptable. As the PropertyGrid does not know what properties it will be displaying, the best it can give the validator is an object - even though the validator knows exactly what type it will be called with.

But as per Mark's answer - most (all?) of the non generic collections in .NET are only there for legacy reasons. If .NET was remade today you can be sure the standard library would look very different.