When you’re working with C# and reflection, you might end up in a situation where you have “lost” the type. For example, if you’ve deserialized an incoming message of some kind, you might have code that needs to do this:

Usually, when you want to do different stuff depending on the type of an object, you just call that object and let it do what it deems reasonable. That’s a good object-oriented way of delegating behavior to objects, totally anti-if campaign compliant and all. But in cases where the object you need to act upon is an incoming DTO, it’s usually not a good approach to put logic on that DTO.

This is a good time to do a “handler lookup” [1. I don’t know if there’s a better name for this pattern. I tried to ask Twitter, but I mostly got “it’s usually not a good idea to do that” – well, most patterns are usually not a good idea: all patterns should be applied only in cases where they make sense </stating-the-obvious>] in your IoC container for something that can handle an object of the given type. It goes like this: Given message: T, find handler: IHandle<T> and invoke handler with message.

In C#, that might look like this:

That’s not too bad I guess, but working at this untyped level for longer than this turns out to be cumbersome and hard to read and understand. It wouldn’t take more than a few lines more of invoking things via reflection before the dispatch of the message has turned into a mess! And then add the fact that exceptions thrown in method invocations made with reflection will be wrapped in TargetInvocationExceptions.

Consider this alternative approach where I use reflection to invoke a private generic method, closing it with the type of the message:

This way, the Dispatch method can have the bulk of the logic and it does not need to bother with the reflection API. Nifty!

Bring back the types!

4 thoughts on “Bring back the types!

  • 2013-03-10 at 10:40
    Permalink

    > “it’s usually not a good idea to do that”

    Well, why not? Did anyone say why not? 🙂

    Maybe it goes down easier, if you simplified the code to this:

    void HandleMessage(object message)
    {
    Dispatch((dynamic)message);
    }

    void Dispatch(TMessage message)
    {
    // whee, we can work with TMessage in here!
    var handler = container.Resolve<IHandle>();
    handler.Handle(message);
    }

    Type arguments are inferred dynamically too.

    Reply
  • 2013-03-10 at 17:45
    Permalink

    Wow, I never actually used dynamic for anything – didn’t realize that it could simply the dispatch so much 🙂

    Reply
  • 2013-03-12 at 10:03
    Permalink

    It’s very easy to do dynamic dispatch in C# due to the dynamic keyword, we use it a couple of places on the project I’m on when we need to specialize handling of types in a hierarchy that were created with Activator. It’s really sweet.

    Reply
  • 2013-09-20 at 03:58
    Permalink

    this is awesome, not sure why the response was cold on twitter. and using the dynamic keyword makes it just so much sweeter. thank you.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: