Using C# Reflection and Expressions for refactoring

June 19, 2020

disclaimer: here is example of refectoring, that is not optimised and well polished. With more experience I'll find better way to achieve what is written here. I have heavy feeling, this is the example of code, that I'll look back N years later with only one thought: "who, the ..., wrote this??"
However, I want to share this experience anyway to have a reference later.

Just imagine situation: you have 40+ classes with same interface and all of them have function with same signature and almost same body except one generic parameter, that is class type itself.

interface IBaseJob
{
    void Run(IJobCancellationToken token);
}

public class ConcreteJob : IBaseJob
{
    public void Run(IJobCancellationToken token)
    {
        /* implementation */
    }

    public Task Execute() =>
        BackgroundJob.Enqueue<ConcreteJob>(job => job.Run(JobCancellationToken.Null));
}

I usually remove unnecesarry classes and types from examples, but these classes from Hangfire library would be important later.

Here I dont like Execute function, that is repeated in several dosen other classes with only small difference:

public Task Execute() => BackgroundJob.Enqueue<AnotherConcreteJob>(job => job.Run(JobCancellationToken.Null));

That sounds like a opportunity to move some functionality into base class. In C#8 it is possible to add interface default implementation, but we still use C# 7.3, so all I could do is to replace interface with abstract class.

public abstract class IBaseJob
{
    public abstract void Run(IJobCancellationToken token);

    public Task Execute(IJobExecutionContext context)
    {
        //@todo: call here BackgroundJob.Enqueue<ThisJobType>(job => job.Run(JobCancellationToken.Null));
    }
}

...and all duplicated Execute functions from all jobs can be thrown away! 🥳 However, we still have a small problem here: How to call Enqueue method properly? We cannot call it directly, because we are not aware of class type in compile time, so we need to construct this function.

In computer science, reflection is the ability of a process to examine, introspect, and modify its own structure and behavior. Not to be confused with Self-Reflection (Philosophy).
Wikipedia

Well-experienced C# developer have access to types, methods and all stuff, that was used to write code, that he is currently writing 🤪 Start with type Type, that describes type. Enqueue is a static function from BackgroundJob, therefore we need this type and get list of methods, that it supports:

typeof(BackgroundJob)   // return Type in runtime
    .GetMethods()       // return list of available methods

At first I thought just to get method by name (.GetMethod("Enqueue")), but there are 4 methods with same name and friendly exception kindly asked me to be less ambiguously. This is a common problem with reflection code: you usually doesnt know if something is wrong in compile time, all errors show itself only when you actually run the code.
So, method, that I needed, is 1) generic and 2) have Expression<Action<T>> as argument. What is an Expression and why they need Action I will explain later.
GetMethod return MethodInfo, class, that describes all information about concrete method. Then we need to call GetParameters to, well, get method parameters. I'll probably better explain it by adding comments into code:

var enqueueMethod = typeof(BackgroundJob)
    .GetMethods() // We have all BackgroundJob methods here
    .Where(m =>
        m.Name == "Enqueue" &&
        m.IsGenericMethod &&
        m.GetParameters().Length == 1) // Filter out only generic, with proper name and one parameter
    .Select(m => new
    {
        method = m,
        paramType = m.GetParameters().Single().ParameterType
    })  // We need to have a paramter type for further investigation and same MethodInfo in tuple to return it later
    .Where(p =>
        p.paramType.GetGenericTypeDefinition() == typeof(Expression<>) &&   // Generic type of argument should be 'Expression<>'
        p.paramType.GetGenericArguments().Length == 1 &&
        p.paramType.GetGenericArguments().First().GetGenericTypeDefinition() == typeof(Action<>)) // We need to go deeper and find generic arguments from generic arguments 🧐
    .Select(p => p.method) // If single parameter has type Expression<Action<>>, we are good
    .Single()   // An I'm sure, that there is only one of them. However, that's a bad practice, if someone update Hangfire version and there would be another method, that will pass by this criteria

And now we have MethodInfo about what we need to call!
Can we can call it? No, not yet.
Remember that 'Action<T>' ? We need to place current job type there. Type can be found easily with GetType(). Difference with typeof is that later is used in runtime, unlike that GetType() user can place current type in compile type, that is what we needed. And then we construct proper method using MakeGenericMethod

var concreteJobType = GetType();
enqueueMethod = enqueueMethod.MakeGenericMethod(concreteJobType);

Now we are talking!
But we still have one small detail - Enqueue method is not just genetic, it take generic argument. And this argument is itself a Expression that take Action as a generic argument, which broke my brain for a second, when I was trying to figure it out.🤯

An expression is a sequence of one or more operands and zero or more operators that can be evaluated to a single value, object, method, or namespace.
Microsoft docs

This haven't done anything clearer for me. Expression is a smallest part of code, that can be described: variable, constant, function or methods argument. Let's say we have code line a + 3. We can represent it as expression, where a would be Expression.Variable, then 3 would be Expression.Constant and whole line would be Expression.Add with previous two as a parameters. Lambda itself can be presented as a Expression too¹. And now we need to build expression, that represent code job => job.Run(JobCancellationToken.Null) where job would be current type.

var cancellationTokenArgument = Expression.Constant(JobCancellationToken.Null, typeof(IJobCancellationToken));
var jobParameter = Expression.Parameter(concreteJobType, "job");
var runMethodInfo = concreteJobType.GetMethod("Run");
var callExpression = Expression.Call(jobParameter, runMethodInfo, cancellationTokenArgument);
var lambda = Expression.Lambda(callExpression, jobParameter);

So, finaly, we got everything: method, that we need to call and parameters to call it. We can do magic with MethodInfo.Invoke:

object[] args = { lambda };
enqueueMethod.Invoke(null, args);

Couple notes to this code:

• Enqueue method is static, therefore first argument to Invoke is null. Otherwise it should be a object, which method is invoked.
• you cant put parameter directly, you need to make array from it. Would be a good opportunity to use variadic arguments with params, but it is what it is.
• don't forget to wrap it in try/case here or catch exceptions somewhere else. As I wrote above, using reflections mean you will get more errors in runtime instead of by compilation.

Whas it all worth it?

So, now we have one function in base class instead of many (many many) small functions in dosens of files. Does code became clearer? I doubt so. Does it faster? Definitly not ². We just followed DRY principle and removed duplicated code. I guess, most valulable benefit, that we gain is the experience in writing code, that works with Reflections and Expressions. In writing day-to-day buiseness logic I not often have a chance to use them 😋
We have another example for using reflections in our project: every time someone add new field to class, that represents possible user rights, startup tool make changes to database to add new fields in users table. Otherwise, Reflections and Expressions are used in more common system code like Linq, Automapper etc.