.NET generics work great for container classes. But what about other uses?Well, it turns out that .NET generics have a major limitation – they require
the type parameter to be constrained. For example, you cannot do this:
static class Disposer
{
public static void Dispose(T obj) { obj.Dispose(); }
}
The C# compiler will refuse to compile this code, as the type T has not been
constrained, and therefore only supports the methods of System.Object.
Dispose is not a method on System.Object, so the compilation fails. To fix
this code, we need to add a where clause, to reassure the compiler that our
type T does indeed have a Dispose method
static class Disposer where T : IDisposable
{
public static void Dispose(T obj) { obj.Dispose(); }
}
The problem is that the requirement for explicit contraints is very limiting.
We can use constraints to say that T implements a particular interface, but
we can’t dilute that to simply say that T implements a particular method.
Contrast this with C++ templates (for example), where no constraint at all is
required – it is assumed (and verified at compile time) that if the code
Satish Marwat Dot Net Web Resources satishcm@gmail.com 32 Page
invokes the Dispose() method on a type, then the type will support the
method.
In fact, after writing generic code with interface constraints, we quickly see
that we haven’t gained much over non-generic interface-based programming.
For example, we can easily rewrite the Disposer class without generics:
static class Disposer
{
public static void Dispose( IDisposable obj ) { obj.Dispose(); }
}