Posts tagged LINQ

Using Expression Trees To Break The Law Of Demeter

I am sure most programmers have heard about the Law Of Demeter, which is the principle that a classshould only have limited knowledge about other classes, and only talk to objects closely related to the current object. This is sometimes presented as "you should not have more than one dot in each expression". In other words, this would be breaking the law:

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;
 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");
 14:             if (ReferenceEquals(arg, null))
 15:                 return default(TResult);
 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:             } 
 25:             if (stack.Count == 0 || !(stack.Peek().Expression is ParameterExpression))
 26:                 throw new ApplicationException(String.Format("The expression '{0}' contains unsupported constructs.",
 27:                                                              expression));
 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:             }
 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:

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) ?

JAOO Day One

Today, I've been attending the first day at the JAOO Conference. It has been an interesting day, and I am amazed by all the very talented people that speaks here at the conference, as well as by the quality of the talks. I have been attending these sessions:

Opening Keynote: Where Are Programming Languages Going, by Anders Hejlsberg
In this talk, Anders presented his take on how the programming languages will be evolving in the future. One point made, was that programming languages has not evolved much over the last 25 years - which was exemplified by a "Hello world" program in Pascal versus one in C#. The C# one was neither the shortest nor the most concise one. Anders believes that we will se more implementation of what he calls "internal domain-specific-languages", such as LINQ. Furthermore, he thinks that in the future the gap between functional and imperative programming languages will diminish, since they are already today starting to borrow the best elements from each other. Finally, he talked about concurrency and in-language concurrency constructs such as isolation, which Anders predicts also will be part of the main-stream languages in the near future.

Continuous Integration
The Continuous Integration talk was a great introduction to me into Continuous integration, since it is something, that I have little to zero experience with. We do have a build server that does nightly builds at work, but as Chris Read, the speaker, pointed out, that is not CI, though it is a step on the way toward succesful CI.

Google Chrome: The Invisible Browser
This was a talk by Ben Goodger, the Google Chrome UI tech lead, about the minimalist Chrome UI and the architecture and decisions behind it. It was interesting, though there was not much new to learn here. (Or perhaps I should know better than to attend UI talks, when UI does not really interest me. I am trying to learn ;-) )

LING and C# 3.0
This was the second talk by Anders Hejlsberg this day, and featured the new features in C# 3.0. This was info that I knew (mostly) in advance, but Anders explained both the how and the why behind the features - which was really interesting.

The talk about PowerShell was really good; even for me who know and use PowerShell in advance. It got beyond the covers on why the architecture and implementation works as it does, which was interesting and enlightening, and I left with a better understanding of PowerShell.

The Scala Programming Language
Scala is a language for the JVM, that I did not know much about in advance. The talk was interesting, but in "real life", I am probably never going to use it.

Why Functional Programming (still) Matters
This talk by Erik Meijer was propably the most interesting and entertaining one on Day One of JAOO. With enthusiasm, Erik explained about side-effects and why they are bad and what one should do about them (make them explicit if they cannot be avoided). He also demonstrated a few side effects, that can hit you in C# or other main stream languages with closures and lambdas, which was a pleasant reminder for me.

Clever use of C# 3.0 LINQ Expressions

Jafar Husain shows us a quite clever way to use a C# 3.0 LINQ expression to get a symbol name. I think this is a really good idea to use in cases when you need the name of a symbol as a string, since it avoids using hard-coded strings and gives us the option to use automatic refactorings without breaking stuff. And since it is implemented as an extension method; it does not pollute the interface of your classes. There might be a slight performance penalty when using this method; but I think it will be neglible for all but some extreme cases. But if you need to use it in a tight loop, you should propably make some performance measurements in advance ;-)

Now, if only C# 3.0 had been available a couple of years ago, when I wrote a lot of statically typed datasets (automatically generated from the database schema using CodeSmith, of course). The bulk of the code in those datasets where properties that would generally retrieve a value from a DataRow in a column named the same as the property. If I could have used the approach mentioned above, I am sure it would have saved me some sweat during later refactorings of the code in question.

It is a Good Thing our tools and languages continually evolves.