Developing For .NET

Tonight I am visiting RVNUG (Roanoke Valley Dot Net Users Group) for the first time. Kathleen Dollard, a columnist for Visual Studio Magazine and author of Code Generation in Microsoft .NET (which I have and have read most of) is the featured presenter. She will be discussing “Refactoring with Generics”. How to make your code better with Generics, using Framework Generics, and how to use and make your own Generics.

Here are some bullets I garnered from the presentation:

• Find out about the Converter<T> Generic Delegate.
• “Team Test” is now part of VS2008.
• Anonymous Delegates employ “Closure” – allows a private variable to be trucked off to (captured by) an out of scope method (like an anonymous delegate)
• Return a LINQ list immediately by using “.ToList()”: no deferred execution
• Format for declaring my own generics and specifying Type inheritance: public class GenericClass<TData, TCollection> : SomeBase where TCollection : List<TData> where TData : class

Conclusions

Overall, a good presentation. Unfortunately, it is a little dated when you consider all the new technologies out there. Kathleen did include some optional approaches using LINQ and Lambdas, but the bulk of the material is still 2.0 based. Don’t get me wrong: I’m not saying I didn’t learn anything because I did. I think I have a much better handle on creating my own generic classes now. But I think the target audience for this presentation should be developers moving from 1.1 to 2.0 or new developers.

Now for the scary part: the topic is very relevant. There are still an incredible number of people developing in pre-2.0 technologies who need this kind of information.

Kathleen is great: if you ever get a chance to go to a presentation of hers, by all means treat yourself: she really knows her stuff. We had a nice talk during dinner about the future of LINQ to SQL, OR/M, the Entity Data Model, and other Framework issues.? She was very patient with my questions and her answers reveal that she is one smart cookie.

I’ve been very busy continuing my C# 3.0 and .NET 3.5 self-education. I’ve been focusing primarily on LINQ, but before I cover that here, which will take several postings, I wanted to cover Lambda Expressions. If you have been reading about LINQ and its related technologies at all, you’ve surely come across this term already. If you’ve already read some about Lambdas, then perhaps you came to the same conclusion I did: a lot of writers covering Lambda Expressions seem to want you to be boggled by them. In most articles, I found myself wading through a bunch of stuff I really did not need to know. In fact, it sometimes simply added more confusion.

So my goal in this article is to bypass all the pocket protector stuff and get right down to brass tacks. Here are a list of things I will NOT be covering that pervade almost every other article about Lambda Expressions:

• Lambda calculus
• Anonymous Methods
• Functional Languages
• Lexical Closures

If you are interested in any of the above, they are plenty of other articles out there. If, however, you are like me and just want to use this stuff, then read on…

Anonymous Methods

Before you scream foul, yes, I said I wasn’t going to discuss these, and really, I’m not. Or more accurately, I’m not going to explain them or show examples. You do have to know that Lambda Expressions are just another way to write Anonymous Methods. *whew*! Glad we got that out of the way!

The tricky part, though, for many programmers is knowing when to use Anonymous Methods. As far as our discussions go, it will be pretty easy: you want to use Anonymous Methods whenever you need to pass a method reference. This is done by use of delegates, something else I’m not really going to talk about.

So what you need to know is this: where ever you see a method that requires a delegate (or a reference to a method), you can use a Lambda Expression instead. An Anonymous Method is just a way to write the code for such a delegated method inline. So, we just need a way to know when we can use Lambda Expressions.

Actions, Predicates, and Funcs

What we need are Delegate Types. Delegate types are declared signatures for method calls that are used to wrap instance methods or, in our case, anonymous methods. Fortunately for us, there are some Generic Delegate Types built in to .NET that we can put to good use.

Action<T>

This is a Generic Delegate defined in .NET that will wrap and execute a method, passing it a variable of type T. Here is the MSDN Documentation. If you use this in a method declaration, you can actually pass a reference to a method, anonymous or otherwise, to a method of your own creation. For an example, check out this Extension Method:

public static void ExecuteOnValues<K, V>(this IDictionary<K, V> sequence, Action<V> action)
{
    if (sequence == null)
    {
        throw new ArgumentNullException("sequence");
    }

    foreach (var item in sequence.Values)
    {
        action(item);
    }
}

You can see here that our method signature expects a Generic Action<T> method reference. What we don’t know is what this method will do. The code line action(item) is saying “execute the method passed in on my action parameter, and pass it the item as a parameter.” So our Action method receives the Value of our Dictionary as a parameter and does something with it. We are going to use Lambda Expressions to define the “something”. Here is a simple example:

var dict = new Dictionary<int, string>();
dict.Add(1, "Coding");
dict.Add(2, "in");
dict.Add(3, "C#");
dict.Add(4, "Rules!");

dict.ExecuteOnValues(f => Console.WriteLine(f.ToString()));

Here we have created a new Dictionary<TKey, TValue> collection and added some data. Because Dictionary<TKey, TValue> inherits from IDictionary<TKey, TValue>, we can use our new Extension Method to execute some code against all the values in our Dictionary. But remember that our Extension Method really has no executing logic: it is expecting us to send it a reference or a delegate to it so it knows what to do. Enter the Lambda Expression. In the ExecuteOnValues method call above, f => Console.WriteLine(f.ToString()) is a Lambda Expression.

Anatomy of a Lambda Expression

// A simple Lambda expression
f => Console.WriteLine(f.ToString())

The “=>” thingy in the middle is the Lambda operator. This is what lets you know a Lambda is what is happening here. Let’s break the rest down into two parts: the left side and the right side. The left side represents a parameter list to be passed into the method. The right side represents the code the method will execute. Really, that’s it. You can make it harder if you want, but ultimately this is all it boils down to. Here is a diagram:

// A simple Lambda expression
f     =>    Console.WriteLine(f.ToString())
PARM Lambda CODE TO EXEUTE

So you can think of this as a method defined like so:

// A faux method representing a Lambda
void Method (unknownType f)
{
    Console.WriteLine(f.ToString());
}

In essence, without getting into all the pocket-protector details, this is what is the compiler is doing for you when it sees a Lambda Expression. The above is psuedo-code, and not entirely accurate, but you get the idea.

Where this gets confusing is that you really don’t see any type declarations, either for the parms or the return value. This is more Compiler Inference at work. In our example above, we specified that our Action generic was based on the Value Type of the Dictionary. The Compiler is able to look at the context of the Lambda Expression and simply infer that f is whatever type we specified on the Action parameter. You could write the details out, specifying the types, but not needing to is one of the major draws of Lambdas: the code is more compact and it “just works”. Now we’ll change our Dictionary to have a different Value type. We’ll make it our standard Person and add some people to it:

var dict2 = new Dictionary<int, Person>()
{
    {1, new Person() {FirstName = "John", LastName = "Smith", Age = 32, DOB = "12/31/1988"}},
    {2, new Person() {FirstName = "Jimmy", LastName = "Crackcorn", Age = 57, DOB = "08/08/1934"}},
    {3, new Person() {FirstName = "Mary", LastName = "Contrary", Age = 44, DOB = "09/10/2000"}}
};
dict2.ExecuteOnValues(f => Console.WriteLine("{0} is a {1} born on {2}", f, f.GetType().Name, f.DOB));

Now if we run this we’ll get these results (Click for full size image):

And now we get to see something else: in this Lambda, I am executing methods and Properties on my parameters. Pretty cool, huh?

So let’s read this Lambda out loud: “GIVEN f, EXECUTE {Console..WriteLine(“{0} is a {1} born on {2}”, f, f.GetType().Name, f.DOB));}”

Confused about the Looping? Don’t be: the loop is actually happening back in our Extension Method. All that’s happening here is that this code is executing (inside the loop) and using each Value from our Dictionary as the GIVEN parameter.

Predicate<T>

This is a Generic Delegate that evaluates a condition and returns true or false. Notice that Action<T> did not return any values. Predicate<T> is different because it returns a boolean value, and ultimately its only purpose is to determine whether or not a certain condition is met. Here is the MSDN documentation.

Let’s create a custom PersonCollection class and add a method that returns a sublist of Person objects who meet an unspecified criteria:

class PersonCollection : List<Person>
{
    public List<Person> MatchingPersons(Predicate<Person> condition)
    {
        List<Person> list = new List<Person>();

        foreach (Person p in this)
        {
            if (condition(p))
            {
                list.Add(p);
            }
        }

        return list;
    }
}

This code is specific to our PersonCollection class but still takes advantage of Predicate<T> to filter itself into a subsetted list. Let’s execute this now and get back just a list of Veterans:

var people = new PersonCollection()
    {new Person() {FirstName = "John", LastName = "Smith", Age = 32, DOB = "12/31/1988", IsMilitaryVeteran=true},
     new Person() {FirstName = "Jimmy", LastName = "Crackcorn", Age = 57, DOB = "08/08/1934", IsMilitaryVeteran=false},
     new Person() {FirstName = "Mary", LastName = "Contrary", Age = 44, DOB = "09/10/2000", IsMilitaryVeteran=true}};

Console.WriteLine("Print them all:");
people.ForEach<person>(f => Console.WriteLine("{0} is a {1} born on {2}", f, f.GetType().Name, f.DOB));
Console.WriteLine();

// Get a subset of people
var veterans = people.MatchingPersons(f => f.IsMilitaryVeteran);
Console.WriteLine("Print just veterans:");
veterans.ForEach<person>(f => Console.WriteLine("{0} is a {1} born on {2}", f, f.GetType().Name, f.DOB));

The beauty here is we did not specify what the criteria for the filtering was: we could have just as easily asked it for all the people whose first names begin with the letter “J”:

// Get another subset of FirstName beginning with "J"
var js = people.MatchingPersons(f => f.FirstName.StartsWith("J"));
Console.WriteLine("Print just Js:");
js.ForEach<person>(f => Console.WriteLine("{0} is a {1} born on {2}", f, f.GetType().Name, f.DOB));

Here is a screen shot of running all three of these in a row (Click for full size image):

Personally, I think this is a great tool, and the Lambda Expressions just make it that much more readable and easy to develop.

Func<T>

So far, we’ve seen Generic Delegates that return void and bool. That’s nice, and we can do a lot with them, but sometimes you need something more. This is where FUNC<T> comes in to play: it can return any type. In this case, the T is the return type. In the MSDN Documentation, they use “TResult” instead of “T”, so I’ll do that too. There are five Func Generic Delegates defined in .NET 3.5:

• Func<TResult> – no parameters, returns type TResult
• Func<T, TResult> – 1 parameter, returns type TResult
• Func<T1, T2, TResult> – 2 parameters, returns type TResult
• Func<T1, T2, T3, TResult> – 3 parameters, returns type TResult (are you noticing a pattern yet?)
• Func<T1, T2, T3, T4, TResult> – 4 parameters, returns type TResult

What’s cool about Func is that you can create your own methods on the fly and give them meaningful names. Here is a simple example:

// Get a subset of people using Func
Func<Person, bool> isVeteranBeginsWithJ = f => f.IsMilitaryVeteran && f.FirstName.StartsWith("J");
Console.WriteLine("Print just veterans whose first name's begin with \"J\":");
foreach (Person p in people)
{
    if (isVeteranBeginsWithJ(p))
    {
        Console.WriteLine("{0} is a {1} born on {2}", p, p.GetType().Name, p.DOB);
    }
}

As you can see, I simply use my Func as any other method. I can see where this would come in very handy for short term reusability. Also, a lot of LINQ elements require Func delegates, so you have to have it in your toolkit.

Some odds and ends

There are a few items that I have to mention. First of all, Action<T> also has a few multiple parameter options:

• Action<T1, T2>
• Action<T1, T2, T3>
• Action<T1, T2, T3, T4>

We did not discuss sending multiple parameters to a Lambda. To do so, wrap them in parentheses, like so:

// Example from Microsoft
(x, y) => x == y

While Compiler Inference is at work here, it is not required. If you wish to specify types for readability you can:

// Example from Microsoft
(int x, int y) => x == y

Calling a Lambda with no parameters, such as Func<TResult> is done with empty parentheses:

Func<string> getSomething = () => "Something";
Console.WriteLine(getSomething());

Lambdas can access local variables:

string todo = "To Do";
Func<string> getSomethingTodo = () => "Something " + todo;
Console.WriteLine(getSomethingTodo());

And Lambdas can be just as complex as you want them to be. Here is a Lambda that receives our custom PersonCollection and calculates the average age based on the DOB (if you’ve looked at the initializers, you’ll find that the Ages and the DOBs do not balance):

Func<PersonCollection, int> calculateAverageAge =
    (PersonCollection c) =>
    {   int totalAges = 0;
        foreach(var p in c)
        {
            string[] parts = p.DOB.Split(new char[] { '/' });
            int year = int.Parse(parts[2]);
            int calcAge = DateTime.Now.Year - year;
            totalAges += calcAge;
        }
        int averageAge = totalAges / people.Count;
        return averageAge;
    };

Console.WriteLine("Average Age of collection is {0}", calculateAverageAge(people));

And lots more. This is hardly the definitive article on Lambdas, but hopefully it explains enough to get you started. There is certainly enough background here to begin using Lambdas with LINQ, which will be next in this series of articles. Here is a link to the MSDN Lambda Expressions (C# Programming Guide).