… oh my!
[Editor's note: For whatever reason, the tool that I'm using to inject the code (with line numbers, which helps with the explanations) likes to mess with the formatting. I hope that the extra white space doesn't detract too much from the article. After typing all of this, really don't want to start debugging CSS issues. ;-)]
Lately, one of the most common questions I've received from students is, basically, "What in the world is this syntax and what does it mean?[1]"
dc.Categories.OrderBy(c => c.Name);
Well – it's a lambda statement. But of course if you haven't seen one, you need a bit more information than that.
Quite frequently, a full explanation would simply take too long or send the class down another path far away from the topic at hand. What I want to do with this post is answer that question fully.
I'm going to answer the question using one of my biggest philosophies when it comes to training, which is to explain it in the way that I understood it, in whatever method it was that made it finally click for me. In this case, that means stepping all the way back to the beginnings and showing essentially the progression that got us to where we are today.
That's going to take a little while here, so bear with me.
Trust me, we'll get there.
Let's take a simple class called Customer that's defined below.
public class Customer
{ public Customer(String firstName, String lastName)
{ this.FirstName = firstName;
this.LastName = LastName;
}
public String FirstName { get; set; } public String LastName { get; set; }
public override String ToString()
{ return LastName + ", " + FirstName;
}
}
Pretty straight forward. Couple of properties, a simple constructor. Looks good. Now let's create a couple, put them into a list, and display them.
1: public static void Main()
2: { 3: List<Customer> customers = new List<Customer>();
4: customers.Add(new Customer("Susan", "Ibach")); 5: customers.Add(new Customer("Christopher", "Harrison")); 6: customers.Add(new Customer("Dave", "Baxter")); 7:
8: foreach (Customer customer in customers) { 9: Console.WriteLine(customer);
10: }
11: }
Again – pretty straight forward[2]. And the output will of course be exactly what we'd expect:
Ibach, Susan
Harrison, Christopher
Baxter, Dave
Now let's see if we can't sort those customers. Fortunately, List has a Sort method. Let's update line 7 to call sort (code below) and run it and see what happens.
customers.Sort(); // Line 7
Result:
Unhandled Exception: System.InvalidOperationException: Failed to compare two elements in the array. ---> System.ArgumentException: At least one object must implement IComparable.
Well that wasn't ideal… In a nutshell, what the runtime is trying to tell us is that we told it to sort a list of customers, but it has no idea how to sort our customers. Makes sense. How do we tell it to sort our customers? Well – by implementing IComparable.
IComparable is an interface with one method – CompareTo(object). CompareTo returns an integer based on the following criteria:
Current object (this) is less than the other object, return a negative number
Current object (this) is equal to the other object, return 0
Current object (this) is greater than the other object, return a positive number
One thing that you'll notice is that every primitive type (and strings) in .NET already implement IComparable. This means we can take advantage of their implementation. Let's update our Customer class to implement IComparable and sort by LastName[3].
1: public class Customer : IComparable
2: { 3: // existing code
4:
5: public int CompareTo(object obj)
6: { 7: // put all NULL objects at the top
8: if(obj == null) return 1;
9:
10: Customer otherCustomer = obj as Customer;
11: if(otherCustomer != null) // obj is a customer
12: return this.LastName.CompareTo(otherCustomer.LastName);
13: else
14: throw new ArgumentException
15: ("Object is not a Customer", "obj"); 16: }
17: }
The breakdown looks a bit like this:
Line 8 – see if the object is null. If it is, move it to the top of the list.
Line 10 – convert the object to a customer
Line 11 – if it turns out that obj is a Customer, use the CompareTo method on String.
Line 13 – if it turns out that obj is not a Customer, throw an ArgumentException.
If we run the code again, we now get the result that we were hoping for:
Baxter, Dave
Harrison, Christopher
Ibach, Susan
Cool.
But…. If you look at the CompareTo implementation, we're having to cast the obj parameter to Customer. Why can't we just tell the IComparable interface that we want people to pass in a Customer and be done with it?
Fortunately – we can. The way that we do this is by using generics. In a nutshell, generics allow you to pass a type as you would a variable. So at design time we tell IComparable prepare itself for Customer objects. Let's update our Customer class again.
1: public class Customer :
2: IComparable, IComparable<Customer>
3: { 4: // existing code
5:
6: public int CompareTo(object obj)
7: { 8: // put all NULL objects at the top
9: if(obj == null) return 1;
10:
11: Customer otherCustomer = obj as Customer;
12: if(otherCustomer != null) // obj is a customer
13: return this.CompareTo(otherCustomer);
14: else
15: throw new ArgumentException("Object is not a Customer", "obj"); 16: }
17:
18: public int CompareTo(Customer other)
19: { 20: // put all NULL objects at the top
21: if(other == null) return 1;
22: return this.LastName.CompareTo(other.LastName);
23: }
24: }
I updated our original CompareTo method to call our new one. The new one is using the same logic as before, and running our code again returns the same result.
Cool – we have a Customer class that can be sorted.
But…. It can only be sorted one way – by LastName. If we wanted to sort by FirstName, well – that'd require updating our class. Having to update our class every time we need a different sort order would be a pain.
Fortunately – we don't have to. The .NET framework also includes an IComparer interface. The difference between IComparable and IComparer is that IComparable is for sorting that specific class (which is why Customer implemented IComparable), while IComparer is for sorting other classes – a utility if you will. Let's create a class that can sort Customer objects by FirstName.
public class CustomerSorter : IComparer<Customer>
{ public int Compare(Customer lhs, Customer rhs)
{ // put nulls at the top of the list
if(lhs == null) return -1;
if(rhs == null) return 1;
return lhs.FirstName.CompareTo(rhs.FirstName);
}
}
The main difference, besides calling CompareTo on FirstName, is that we have two parameters of type Customer and we're comparing one to the other. But the logic is still basically the same.
To use the new sorter, we simply pass a new instance of the object into the Sort method on List.
// all other code identical
customers.Sort(new CustomerSorter());
When we run the code now, we get everything sorted by FirstName.
Harrison, Christopher
Baxter, Dave
Ibach, Susan
Cool.
But… If we have to create a new class every single time we need to change the sort order, well – that's going to stink. There's gotta be a better way.
Fortunately, there is. The .NET Framework gives us the ability to use delegates, which allow us to pass methods like we would objects.
Let's take a look at our new Compare() method that we created on our CustomerSorter class. You'll notice that it takes two parameters, each of type Customer, and returns an integer. That's it. And when we call Sort and pass in the CustomerSorter, it simply calls that method. Why can't we just pass a method into Sort?
This is where that delegate, an object that points to a method, comes into play. Since it can be used like an object and passed in as a parameter, we can just tell Sort to call that method directly. This is really the same thing we were doing before by passing in an instance of CustomerSorter to the Sort method, only this time we're just passing in a method.
Our method just needs to match the same signature – two Customer parameters and return an integer.
Let's add a method to our Program class that will use the same logic as our CustomerSorter.
// added to Program class
private static int SortByFirstName(Customer lhs, Customer rhs)
{ // put nulls at the top of the list
if(lhs == null) return -1;
if(rhs == null) return 1;
return lhs.FirstName.CompareTo(rhs.FirstName);
}
Want to know a secret? I simply copied and pasted from the CustomerSorter class and changed public to private , instance to static, and the name to SortByFirstName.
Now we just need to tell the Sort method to use our new SortByFirstName method.
// identical code except for Sort call
customers.Sort(SortByFirstName);
And as before, the result is the same – sorted by FirstName.
Cool.
But... If we need to sort in several different orders, we don't want to have to create a method each and every time. Wouldn't it be nice if we could just inject the logic right into the call to Sort?
Fortunately, we can. We do this by creating an anonymous method. An anonymous method is a method that has no name. We just create the method signature by using a delegate, and pass it right into the Sort method.
// identical code except for the Sort method
customers.Sort(delegate(Customer lhs, Customer rhs) { if (lhs == null) return -1;
if (rhs == null) return 1;
return lhs.FirstName.CompareTo(rhs.FirstName);
});
Just as before, we have the same logic (yes, I copied and pasted). We're just declaring the method just as we normally would with only a couple of differences. First, we're using the keyword delegate instead of using a method name. Second, we're not specifying a return type. The reason is that Sort already knows what the return type is – an integer – so the compiler doesn't require it.
And, as before, the result is the same – sorted by FirstName.
Cool.
But... Why do we have to specify the types of the parameters? After all, we already told the list right up front that we were using Customer objects.
Fortunately, we don't. This is where lambda expressions come into play. A lambda expression is just like an anonymous method, only with a couple more assumptions. In our case, since we know, and the compiler knows, that we are only dealing with Customer objects, and we need to return an integer, we're just going to declare our variables and move on.
// identical code except for call to Sort
customers.Sort((lhs, rhs) => { if (lhs == null) return -1;
if (rhs == null) return 1;
return lhs.FirstName.CompareTo(rhs.FirstName);
});
The main difference between this and our anonymous method is the syntax and the fact that we're not declaring data types. Since everyone, including the compiler, knows that lhs and rhs can only be Customer objects we don't have to declare it. The => is just the syntax to indicate the start of the method, or lambda expression.
And, as before, the result is the same – sorted by FirstName. Cool.
But... What about the normal situation where all we want to do is just say, "Hey .NET – sort this by ___ for me."? Do we really have to create a method, even in a lambda expression, every single time?
Fortunately, we don't. This is where Language Integrated Query (LINQ) comes into play.
In each of our method implementations, our code has simply taken advantage of the logic in the String class. LINQ will do the same thing for us. We simply tell LINQ, "Hey – sort by this", and it'll handle the translations for us.
The first step to using LINQ is to leave behind the Sort method that we've come to know and love. Unfortunately, Sort doesn't support LINQ.
When Microsoft introduced LINQ, they also introduced something called extension methods.[4] Extension methods are a way of adding a method to an existing class without having to inherit from that class. The method that was added to the List class, or more specifically IEnumerable, for LINQ was OrderBy.
With OrderBy we can, by using a lambda statement[5], simply tell LINQ the property we want to sort by. So the new code looks like this:
1: // updating the foreach loop
2: // all other code remains the same
3: foreach (Customer customer in
4: customers.OrderBy(c => c.FirstName)) { 5: Console.WriteLine(customer);
6: }
Couple of things to notice here.
First up is that unlike Sort, OrderBy is volatile, meaning that it's going to return the sorted list rather than updating the list like Sort did.
Second is the fact that we're not returning an integer. Again, LINQ will handle the translation for us. As long as we specify a property that implements IComparable it will use that for the sorting.
Third is that LINQ uses deferred execution. In other words, it won't actually do the sort until we use the results. In this case, we're doing this when we use the foreach loop.
And now when we run the code we of course get the same results.
Cool.
And that's what that lambda statement is all about. It's really just letting someone else create the query for us based on a couple of assumptions about our code and the types that we're using.
From here, things actually get cooler. We of course have LINQ syntax, which allows us to write something similar to a SQL query. And, LINQ can also translate the queries for other environments, like SQL.
But for now, we'll leave it here, with a very propeller head view of lambda statements. Hopefully this helped bring together what's happening behind the scenes, and why we're able to take the shortcuts we can take.
And as always, if you want the source code, feel free.
[1] Or some variation of that syntax or that question.
[2] The one thing that might be unfamiliar is the <Customer>, or generics, syntax. We'll actually address that in a little while.
[3] Keep in mind this isn't a full implementation of IComparable. We really should implement IEquatable, and consider overloading the associated operators. But that's a topic for another blog post.
[4] Extension methods are worthy of another blog post.
[5] A lambda statement is just like a lambda expression – just one line instead of multiple lines.
