Using Expression Trees To Break The Law Of Demeter

string name = order.Customer.Name;

While I do appreciate the idea behind the Law Of Demeter, specifically that individual classes should not know too much about each other; I think the above code would often be perfectly acceptable. Phil Haack has a blogpost going into further details about this: The Law of Demeter Is Not A Dot Counting Excercise, and others agree. I think Martin Fowler explains it best: "I'd prefer to call it the Occasional Useful Suggestion of Demeter".

So, most of us will probably (hopefully) agree, that it is OK to use more than one dot in a statement, when appropiate. One such place might be when doing UI in a ASP .NET application, and one needs to display information about an order and it's details. But here arises a problem, we will need to check each of the expression parts for null to ensure that we do not accidentally cause a NullReferenceException. This leads to ugly code, especially in a data-binding scenario, such as:

<%# order == null ? null : order.Customer == null ? null : order.Customer.Name %>

This question on StackOverflow asks about exactly that, how do we get rid of such explicit and repeated null checking ? It got me thinking, it must be possible to solve this using expression trees. It turns out, it is in fact possible, as I state in my answer on StackOverflow. We can in fact build an extension methods, which looks at an expression tree, evaluates each part of it seperately, checks for null each time, and ultimately returns the correct value; or null if one of the expression parts where null. This is my implementation of such a method:

 1: using System;

 2: using System.Collections.Generic;

 3: using System.Linq.Expressions;

 4:  

 5: namespace dr.IfNotNullOperator.PoC

 6: {

 7:     public static class ObjectExtensions

 8:     {

 9:         public static TResult IfNotNull<TArg,TResult>(this TArg arg, Expression<Func<TArg,TResult>> expression)

 10:         {

 11:             if (expression == null)

 12:                 throw new ArgumentNullException("expression");

 13:  

 14:             if (ReferenceEquals(arg, null))

 15:                 return default(TResult);

 16:  

 17:             var stack = new Stack<MemberExpression>();

 18:             var expr = expression.Body as MemberExpression;

 19:             while(expr != null)

 20:             {

 21:                 stack.Push(expr);

 22:                 expr = expr.Expression as MemberExpression;

 23:             } 

 24:  

 25:             if (stack.Count == 0 || !(stack.Peek().Expression is ParameterExpression))

 26:                 throw new ApplicationException(String.Format("The expression '{0}' contains unsupported constructs.",

 27:                                                              expression));

 28:             

 29:             object a = arg;

 30:             while(stack.Count > 0)

 31:             {

 32:                 expr = stack.Pop();

 33:                 var p = expr.Expression as ParameterExpression;

 34:                 if (p == null)

 35:                 {

 36:                     p = Expression.Parameter(a.GetType(), "x");

 37:                     expr = expr.Update(p);

 38:                 }

 39:                 var lambda = Expression.Lambda(expr, p);

 40:                 Delegate t = lambda.Compile();                

 41:                 a = t.DynamicInvoke(a);

 42:                 if (ReferenceEquals(a, null))

 43:                     return default(TResult);

 44:             }

 45:  

 46:             return (TResult)a;            

 47:         }

 48:     }

 49: }

There are some caveats though, in the current version it will only work with simple member access, and it only works on .NET Framework 4, because it uses the MemberExpression.Update method, which is new in v4.

It works by examining the expression tree representing your expression, and evaluating the parts one after the other; each time checking that the result is not null.

I am sure this could be extended so that other expressions than MemberExpression is supported, and I might update it at a later point to support more complicated expressions. Consider this as proof-of-concept code, and please keep in mind that there will be a performance penalty by using it (which will probably not matter in many cases, but don't use it in a tight loop :-) ). I have not done any measurements on the performance yet, and I am also sure that one could make some optimizations to it.

Here is a zip containing the code as well as a few unit tests: IfNotNullExtension.zip.

What do you think about this approach to null checking ? Would you consider this extension method useful (provided that it performs adequately for the scenario) ?