Why use generic constraints in C#

Question

I've read an excellent article on MSDN regarding Generics in C#.

The question that popped in my head was - why should i be using generic constraints?

For example, if I use code like this:

public class MyClass<T> where T : ISomething
{
}

can't I switch ALL references of T in this class with ISomething?

What's the benefit of using this approach?

Answer 1

You ask, "can't I switch ALL references of T in this class with ISomething?" So I think you mean to compare:

public class MyClass<T> where T : ISomething 
{ 
    public T MyProperty { get; set; }
}

With:

public class MyClass 
{
    public ISomething MyProperty { get; set; }
}

In the second example, MyProperty is only guaranteed to be an instance of ISomething. In the first example, MyProperty is whatever T is, even if that is a specific subtype of ISomething. Consider a concrete implementation of ISomething:

public class MySomething : ISomething
{
    public string MyOtherProperty { get; set; }
}

Now, if we use the first, generic, example, we could have:

MyClass<MySomething> myClass = new MyClass<MySomething>();
Console.WriteLine(myClass.MyProperty.MyOtherProperty);

On the other hand, if we used the second example, we wouldn't be able to access MyOtherProperty since it's only known to be an ISomething:

MyClass myClass = new MyClass();
Console.WriteLine(myClass.MyProperty.MyOtherProperty); // Won't compile, no property "MyOtherProperty"

On a different note, the reason these type constraints are useful is that you can refer to MyProperty (type T) and access members of ISomething. In other words, if ISomething were declared like:

public interface ISomething 
{
    public string SomeProperty { get; set; }
}

Then you could access MyProperty.SomeProperty. If you omitted the where T : ISomething then you wouldn't be able to access SomeProperty since T would only be known to be of type object.

Answer 2

Type Safety. For example, suppose you're creating a container. You can pass in something to that container and retrieve it in the proper form without having to do any casts later by parameterizing the container. You're simply defining constraints on the types of things that you're willing to store in your container.

Answer 3

Here's an example of the difference, by just using List<>

Image list wouldn't be generic but it would just use IListElement everywhere it used the generic instead. Now Imagine you have an object that's something like this.

class Element : IListElement
{
   public string Something { get; set; }
}

now I could just do list.Add(element); and there wouldn't be a difference with a real List<Element>. However when I retreive data it's a different story, if I use the list that uses IListElement then I have to cast my data back so I can get the Something out of it. Thus i'd have to do:

string s = ((Element)list[0]).Something;

while with the generic I can just do:

string s = list[0].Something;

saves a lot of trouble, ofcourse it goes a bit further than that but I think you can get the idea from this.