Bring back the types!

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!

4 thoughts on “Bring back the types!

  1. > “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)

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

    Type arguments are inferred dynamically too.

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

  3. 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.

  4. 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.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.