When building complex applications, a certain level of abstraction becomes a necessity. Developers try to make their application as flexible as possible with minimal effort applied to do this by generalizing their code to be built on top of a common reusable structure rather than be made of hard-coded parts.

This also applies to functions that are used across an application. In many cases, the result of a function is returned directly as a parameter to another function. Let’s look at a specific example.

I have a method that generates a MD5 hash based on the string that is passed to it:

public static string GetMD5Hash(string password)
{
    byte[] data;
    data = Encoding.ASCII.GetBytes(password);
    MD5CryptoServiceProvider crypto = new MD5CryptoServiceProvider();
    crypto.ComputeHash(data);
    data = crypto.Hash;
    string c = BitConverter.ToString(data);
    return c;
}

The only problem with the returned string is the fact that it contains dashes and is in upper case – but there is a method that can fix that.

public static string RemoveDash (string source)
{
    return source.Replace("-", string.Empty).ToLower();
}

In a regular case scenario, you could use something like this:

Console.WriteLine(RemoveDash(GetMD5Hash("YourTextHere")));

Once GetMD5Hash will have a string to return, it will be passed to RemoveDash. But there is one problem with the approach I am using here – the call itself is not flexible.

.NET Framework 3.5 came out with a new type of delegate: Func<T, TResult>, that allows you to encapsulate a method call that will follow the structure defined by the delegate. That way, as you can see the delegate itself doesn’t specify what data it should get – there are no explicit type declarations. Instead, a generic type parameter is used.

In my case, I can use Func this way:

public static Func<T, V> GetData<T,U,V>(Func<T,U> firstFunction, Func<U,V> secondFunction)
{
    return n => secondFunction(firstFunction(n));
}

This will combine two other functions passed as parameters into one single call. It is important to mention that these functions can’t be any functions but rather those that abide the structure defined in the delegate.

Initially, I have Func<T,V> - it will be a function that accepts a parameter of type T and will return a result of type V. GetData itself is a function that operates with three types – the same T and V, plus the U and here is why. When the first function is called, the source parameter of type T is passed to it and the result of type U is returned. Then, that result of type U is passed to the second function as a parameter and the returned result of type V is passed to the source function – that will eventually pass that result to the part of the program that invoked it.

Eventually I am taking n, that represents the passed parameter of type T and I am implementing the same nested pattern for function invoking as I did in this article before I started using Func<T,TResult>. However, with the help of Func<T, TResult> I can use the same delegate for a wide variety of other functions that are manipulating data of other types, not only string - now that could be really efficient when it comes to code flexibility and re-use.

In the application itself, I am calling GetData this way:

var result = GetData<string,string,string>(GetMD5Hash, RemoveDash)("YourTextHere");

The returned result type is automatically inferred from the pattern used in GetData - in my case this will be System.String.

Note that although I am using one parameter here, when I am using Func, I can pass as many as 16 parameters to the delegate, so for most of the cases this is more than enough.