Practical uses of generics in .net (Besides the ones in the framework)

Question

I know the theory, they are awesome, the ones included in the framework simplify many things, they even have performance gain.
There are many answers about this topic with very nice examples but typically with low practical value to me or examples that are already present in the framework.

The question is, in which cases you decide to write a class of your own that uses generics?

Answer 1

I'm using generics every time I need to apply same algorithm / same logic on different types of objects.

Example is generic repository:

public interface IRepository<T> where T : class, IEntity
{
  IQueryable<T> GetQuery();
  void Update(T entity);
  void Insert(T entity);
  void Delete(int id);
}

public interface IEntity
{
  int Id { get; set; }
}

Answer 2

I use generics whenever a class performs a set of operations on a yet-to-be-defined type.

For instance, imagine that you implement a set of mathematical operations, but would like the user of your class to be able to decide the actual number type (int, short, ...). By not specifying a type (by making it generic), the generic class can be more widely used.

Another, related, benefit is that the code generated for the generic class will actually be more specific, using eg. less cast operations and potentially less run-time tests. The generic containers in the .NET framework are a good example.

Answer 3

Wow - too many examples (that are potentially too involved for a quick SO answer...) that I can give.

I use generics in many many places (especially to wrap up common patterns that apply in many scenarios). However, one of the most benefitial uses to which I've put them is to speed up reflection-based or other dynamic code which will change depending on the type of an operand, whilst simultaneously hiding it away.

So, for example (a fictional one because my real-world examples will be too involved and abstract without a lot of background) , let's say I have a component which uses strings to retrieve data values from objects almost exclusively. Of course, if it did it once or twice then not a problem, keep the reflection, but if it does it a lot then what you want to do is to compile dynamic delegates that can retrieve the values much faster. So,

public static class NamedValueAccessor<T>
{
  private Dictionary<string, Func<T, object>> _accessors;
  private Dictionary<string, Action<T, object>> _writers;

  public object GetValue(T instance, string name) { }
  public void SetValue(T instance, string name, object newValue) { }
}

GetValue and SetValue can reflect over the type T for its properties, checking the CanRead and CanWrite values of PropertyInfo. Once everything's confirmed as being okay, they can dynamically build a Read/Write delegate using System.Linq.Expressions (easy, since all the reflection info is available) and cache it in the dictionary.

Oh yeah - forgot in my first draft - note that the SetValue delegates can only be compiled with expressions in .Net 4.0 unless you are writing the IL manually.

With this as the base you can then use this class in other generics, perhaps extension methods:

public static GetPropertyValue<T>(this T instance, string name)
{
  return NamedValueAccessor<T>.GetValue(instance, name);
}

Which, because it has no constraints can apply to all types.

And also by reflection if all you have is, say, an object - you can use it's GetType() method to get the runtime type, do a typeof(NamedValueAccessor).MakeGenericType(o.GetType()).GetMethod(...).Invoke(...). Following the same pattern, however, in this case you're better of building a dynamic cache of delegates for each Type that are baked over the correct NamedValueAccessor<T>.GetValue method for the incoming type.

UPDATE

So, to explain what the generic has done for us in this example:

1) Type-based property caches will be resolved by the compiler if the generic type parameter is known at compile time (i.e. NamedValueAccessor<MyType>.GetValue("Foo")) compiles to a particular instance of the generic. All that remains to be done at run time is lookup the delegate in the dictionary and execute it.

2) The caches for separate types are kept apart

3) The caches can be primed in the static class' static constructor with a simple reflection over the type to get all the properties that would be supported and pre-compiling all the delegates. Of course you have to be careful with this code to make sure it can't throw a runtime error - nobody likes TypeInitializationExceptions. If you do this, then you don't have to worry about multithreaded environments either - the cache is immutable.

On point 3 - if the type is an IDynamicObject, then of course this strategy fails - but you can delegate to the instance's dynamic interface.

END UPDATE

In practise, my use of this is to do more complicated things than just wrapping property setters and getters (the code in the ComponentModel namespace is probably better for this - as in the way that Mvc leverages it), but properly woven these kinds of solutions provide excellent performance and accessibility to the end-user (the application coder in my case).

I also expect that this answer will be too abstract to get any votes, but I'm throwing it out there anyway because we don't provide answers to get votes - but to inform the person asking the question :)

Answer 4

I've used generics to add an extension method to objects that implement a couple of interfaces, so

public static MyExtension<T>(this T myobject) where T : ISomeInterface, ISomeOtherInterface
{
   //Do some stuff on myObject
}