Is it a bad idea to use Generic Types to 'switch on types'?

Question

Related to C# - Is there a better alternative than this to 'switch on type'?

I need to 'switch on types': given a parameter of type T, find and execute a method of the form void Method (T param).

This could be solved with a switch statement or a Dictionary<Type, Action>, however I would like to avoid the casts necessary in such scenarios.

I couldn't find the following approach mentioned in the above (or similar) questions:

1. Create a static generic type that acts as collection:

   public static class Commands<T> {
     public static Action<T> Handler;
   }
   

2. Create a repository which uses that type like a type-safe dictionary:

   public class CommandRepository {
       public void Register<T>(Action<T> handler) {
           Commands<T>.Handler = handler;
       }
   
       public void Run<T>(T parameter) {
           // null checks etc.
           Commands<T>.Handler(parameter);
       }
   }
   

3. Example usage:

   public void CreateUser(CreateUserParams p) {
       Console.WriteLine("Creating " + p.Name);
   }
   
   // ...
   var repo = new CommandRepository();
   
   repo.Register<CreateUserParams>(CreateUser);
   repo.Register<DeleteUserParams>(DeleteUser);
   
   repo.Run(new CreateUserParams { Name = "test" });
   repo.Run(new DeleteUserParams { Name = "test" });
   

As mentioned before, the same behavior could be achieved with a Dictionary<Type, Action> in the ComandRepository, but then I would have to cast either the method parameter or, if I use interfaces instead of Action, cast to an IFoo<T> after acquiring an dictionary item.

My question is: Is it OK to (ab-)use generic types like that (given a large number of possible values for T)?

(Bonus question) If it isn't OK, why exactly not? What are the costs / negative effects this would cause?

A final note: I realize this doesn't work for type hierarchies or interfaces. Type T must be matched exactly, which in my scenario is fine.

Edit: I found out that Jil, a JSON serializer, also relies on this pattern. See the TypeCache type, which stores a delegate to serialize an object of type T (as far as I've understood from skimming through code). Since this TypeCache will store a large amount of types I suppose the pattern is generally not problematic.

It would still be interesting to know whether types or their static members need to be garbage collected or if there are other performance implications that need to be considered.

Answer 1

The approach you suggest is workable but has the disadvantage that your repository is effectively a singleton. If you ever find yourself needing a repository which doesn't behave like a singleton, you may find the ConditionalWeakTable[1] type helpful. The trick with using one of those is that for each type of interest you would have a singleton ConditionalWeakTable which maps your objects to the thing (if any) associated with that type. That class is only available in .NET 4.0, but can do some wonderful things.

[1] http://msdn.microsoft.com/en-us/library/dd287757.aspx

As an example, suppose one wanted a type OutTypeKeyedDictionary which supports a SetValue<T>(T Value) and bool TryGetValue<T>(out T Value). One could use a static class family OutputMappers<T>, each class of which which held a singleton instance of ConditionalWeakTable<OutTypeKeyedDictionary, T>. The OutTypeKeyedDictionary wouldn't actually have any fields(!); rather, each instance would be used purely as an identity token which would be used as a ConditionalWeakTable key. Incidentally, the reason that class is in the CompilerServices namespace rather than Collections is that it is used heavily by things like ExpandoObject.

Answer 2

The usual way to implement double dispatch in language like C# that provide only single dispatch, is the Visitor pattern. Your example would look as follows:

Interfaces:

interface IVisitor
{
    void VisitCreateUserParams(CreateUserParams p);

    void VisitDeleteUserParams(DeleteUserParams p);
}

interface IParams
{
    void Accept(IVisitor visitor);
}

Command parameters:

class CreateUserParams : IParams
{
    public void Accept(IVisitor visitor) { visitor.VisitCreateUserParams(this); }

    public string Name { get; set; }
}

class DeleteUserParams : IParams
{
    public void Accept(IVisitor visitor) { visitor.VisitDeleteUserParams(this); }

    public string Name { get; set; }
}

Commands:

class CommandHandler : IVisitor
{
    public void VisitCreateUserParams(CreateUserParams p)
    {
        Console.WriteLine("Creating " + p.Name);
    }

    public void VisitDeleteUserParams(DeleteUserParams p)
    {
        Console.WriteLine("Deleting " + p.Name);
    }
}

Example usage:

var handler = new CommandHandler();

new CreateUserParams { Name = "test" }.Accept(handler);
new DeleteUserParams { Name = "test" }.Accept(handler);