Once again, in this series of posts I look at the parts of the .NET Framework that may seem trivial, but can help improve your code by making it easier to write and maintain. The index of all my past little wonders posts can be found here.
Back in one of my three original “Little Wonders” Trilogy of posts, I had listed generic delegates as one of the Little Wonders of .NET. Later, someone posted a comment saying said that they would love more detail on the generic delegates and their uses, since my original entry just scratched the surface of them.
Last week, I began our look at some of the handy generic delegates built into .NET with a description of delegates in general, and the Action family of delegates. For this week, I’ll launch into a look at the Func family of generic delegates and how they can be used to support generic, reusable algorithms and classes.
Quick Delegate Recap
Delegates are similar to function pointers in C++ in that they allow you to store a reference to a method. They can store references to either static or instance methods, and can actually be used to chain several methods together in one delegate.
Delegates are very type-safe and can be satisfied with any standard method, anonymous method, or a lambda expression. They can also be null as well (refers to no method), so care should be taken to make sure that the delegate is not null before you invoke it.
Delegates are defined using the keyword delegate, where the delegate’s type name is placed where you would typically place the method name:
1: // This delegate matches any method that takes string, returns nothing
2: public delegate void Log(string message);
This delegate defines a delegate type named Log that can be used to store references to any method(s) that satisfies its signature (whether instance, static, lambda expression, etc.).
Delegate instances then can be assigned zero (null) or more methods using the operator = which replaces the existing delegate chain, or by using the operator += which adds a method to the end of a delegate chain:
1: // creates a delegate instance named currentLogger defaulted to Console.WriteLine (static method)
2: Log currentLogger = Console.Out.WriteLine;
3:
4: // invokes the delegate, which writes to the console out
5: currentLogger("Hi Standard Out!");
6:
7: // append a delegate to Console.Error.WriteLine to go to std error
8: currentLogger += Console.Error.WriteLine;
9:
10: // invokes the delegate chain and writes message to std out and std err
11: currentLogger("Hi Standard Out and Error!");
While delegates give us a lot of power, it can be cumbersome to re-create fairly standard delegate definitions repeatedly, for this purpose the generic delegates were introduced in various stages in .NET. These support various method types with particular signatures.
Note: a caveat with generic delegates is that while they can support multiple parameters, they do not match methods that contains ref or out parameters. If you want to a delegate to represent methods that takes ref or out parameters, you will need to create a custom delegate.
We’ve got the Func… delegates
Just like it’s cousin, the Action delegate family, the Func delegate family gives us a lot of power to use generic delegates to make classes and algorithms more generic. Using them keeps us from having to define a new delegate type when need to make a class or algorithm generic.
Remember that the point of the Action delegate family was to be able to perform an “action” on an item, with no return results. Thus Action delegates can be used to represent most methods that take 0 to 16 arguments but return void. You can assign a method
The Func delegate family was introduced in .NET 3.5 with the advent of LINQ, and gives us the power to define a function that can be called on 0 to 16 arguments and returns a result. Thus, the main difference between Action and Func, from a delegate perspective, is that Actions return nothing, but Funcs return a result.
The Func family of delegates have signatures as follows:
Func<TResult> – matches a method that takes no arguments, and returns value of type TResult.
Func<T, TResult> – matches a method that takes an argument of type T, and returns value of type TResult.
Func<T1, T2, TResult> – matches a method that takes arguments of type T1 and T2, and returns value of type TResult.
Func<T1, T2, …, TResult> – and so on up to 16 arguments, and returns value of type TResult.
These are handy because they quickly allow you to be able to specify that a method or class you design will perform a function to produce a result as long as the method you specify meets the signature.
For example, let’s say you were designing a generic aggregator, and you wanted to allow the user to define how the values will be aggregated into the result (i.e. Sum, Min, Max, etc…). To do this, we would ask the user of our class to pass in a method that would take the current total, the next value, and produce a new total.
A class like this could look like:
1: public sealed class Aggregator<TValue, TResult>
2: {
3: // holds method that takes previous result, combines with next value, creates new result
4: private Func<TResult, TValue, TResult> _aggregationMethod;
5:
6: // gets or sets the current result of aggregation
7: public TResult Result { get; private set; }
8:
9: // construct the aggregator given the method to use to aggregate values
10: public Aggregator(Func<TResult, TValue, TResult> aggregationMethod = null)
11: {
12: if (aggregationMethod == null) throw new ArgumentNullException("aggregationMethod");
13:
14: _aggregationMethod = aggregationMethod;
15: }
16:
17: // method to add next value
18: public void Aggregate(TValue nextValue)
19: {
20: // performs the aggregation method function on the current result and next and sets to current result
21: Result = _aggregationMethod(Result, nextValue);
22: }
23: }
Of course, LINQ already has an Aggregate extension method, but that works on a sequence of IEnumerable<T>, whereas this is designed to work more with aggregating single results over time (such as keeping track of a max response time for a service).
We could then use this generic aggregator to find the sum of a series of values over time, or the max of a series of values over time (among other things):
1: // creates an aggregator that adds the next to the total to sum the values
2: var sumAggregator = new Aggregator<int, int>((total, next) => total + next);
3:
4: // creates an aggregator (using static method) that returns the max of previous result and next
5: var maxAggregator = new Aggregator<int, int>(Math.Max);
So, if we were timing the response time of a web method every time it was called, we could pass that response time to both of these aggregators to get an idea of the total time spent in that web method, and the max time spent in any one call to the web method:
1: // total will be 13 and max 13
2: int responseTime = 13;
3: sumAggregator.Aggregate(responseTime);
4: maxAggregator.Aggregate(responseTime);
5:
6: // total will be 20 and max still 13
7: responseTime = 7;
8: sumAggregator.Aggregate(responseTime);
9: maxAggregator.Aggregate(responseTime);
10:
11: // total will be 40 and max now 20
12: responseTime = 20;
13: sumAggregator.Aggregate(responseTime);
14: maxAggregator.Aggregate(responseTime);
The Func delegate family is useful for making generic algorithms and classes, and in particular allows the caller of the method or user of the class to specify a function to be performed in order to generate a result.
What is the result of a Func delegate chain?
If you remember, we said earlier that you can assign multiple methods to a delegate by using the += operator to chain them. So how does this affect delegates such as Func that return a value, when applied to something like the code below?
1: Func<int, int, int> combo = null;
2:
3: // What if we wanted to aggregate the sum and max together?
4: combo += (total, next) => total + next;
5: combo += Math.Max;
6:
7: // what is the result?
8: var comboAggregator = new Aggregator<int, int>(combo);
Well, in .NET if you chain multiple methods in a delegate, they will all get invoked, but the result of the delegate is the result of the last method invoked in the chain. Thus, this aggregator would always result in the Math.Max() result. The other chained method (the sum) gets executed first, but it’s result is thrown away:
1: // result is 13
2: int responseTime = 13;
3: comboAggregator.Aggregate(responseTime);
4:
5: // result is still 13
6: responseTime = 7;
7: comboAggregator.Aggregate(responseTime);
8:
9: // result is now 20
10: responseTime = 20;
11: comboAggregator.Aggregate(responseTime);
So remember, you can chain multiple Func (or other delegates that return values) together, but if you do so you will only get the last executed result.
Func delegates and co-variance/contra-variance in .NET 4.0
Just like the Action delegate, as of .NET 4.0, the Func delegate family is contra-variant on its arguments. In addition, it is co-variant on its return type. To support this, in .NET 4.0 the signatures of the Func delegates changed to:
Func<out TResult> – matches a method that takes no arguments, and returns value of type TResult (or a more derived type).
Func<in T, out TResult> – matches a method that takes an argument of type T (or a less derived type), and returns value of type TResult(or a more derived type).
Func<in T1, in T2, out TResult> – matches a method that takes arguments of type T1 and T2 (or less derived types), and returns value of type TResult (or a more derived type).
Func<in T1, in T2, …, out TResult> – and so on up to 16 arguments, and returns value of type TResult (or a more derived type).
Notice the addition of the in and out keywords before each of the generic type placeholders. As we saw last week, the in keyword is used to specify that a generic type can be contra-variant -- it can match the given type or a type that is less derived. However, the out keyword, is used to specify that a generic type can be co-variant -- it can match the given type or a type that is more derived.
On contra-variance, if you are saying you need an function that will accept a string, you can just as easily give it an function that accepts an object. In other words, if you say “give me an function that will process dogs”, I could pass you a method that will process any animal, because all dogs are animals.
On the co-variance side, if you are saying you need a function that returns an object, you can just as easily pass it a function that returns a string because any string returned from the given method can be accepted by a delegate expecting an object result, since string is more derived. Once again, in other words, if you say “give me a method that creates an animal”, I can pass you a method that will create a dog, because all dogs are animals.
It really all makes sense, you can pass a more specific thing to a less specific parameter, and you can return a more specific thing as a less specific result. In other words, pay attention to the direction the item travels (parameters go in, results come out). Keeping that in mind, you can always pass more specific things in and return more specific things out.
For example, in the code below, we have a method that takes a Func<object> to generate an object, but we can pass it a Func<string> because the return type of object can obviously accept a return value of string as well:
1: // since Func<object> is co-variant, this will access Func<string>, etc...
2: public static string Sequence(int count, Func<object> generator)
3: {
4: var builder = new StringBuilder();
5:
6: for (int i=0; i<count; i++)
7: {
8: object value = generator();
9: builder.Append(value);
10: }
11:
12: return builder.ToString();
13: }
Even though the method above takes a Func<object>, we can pass a Func<string> because the TResult type placeholder is co-variant and accepts types that are more derived as well:
1: // delegate that'
s typed to return string.
2: Func<string> stringGenerator = () => DateTime.Now.ToString();
3:
4: // This will work in .NET 4.0, but not in previous versions
5: Sequence(100, stringGenerator);
Previous versions of .NET implemented some forms of co-variance and contra-variance before, but .NET 4.0 goes one step further and allows you to pass or assign an Func<A, BResult> to a Func<Y, ZResult> as long as A is less derived (or same) as Y, and BResult is more derived (or same) as ZResult.
Sidebar: The Func and the Predicate
A method that takes one argument and returns a bool is generally thought of as a predicate. Predicates are used to examine an item and determine whether that item satisfies a particular condition. Predicates are typically unary, but you may also have binary and other predicates as well.
Predicates are often used to filter results, such as in the LINQ Where() extension method:
1: var numbers = new[] { 1, 2, 4, 13, 8, 10, 27 };
2:
3: // call Where() using a predicate which determines if the number is even
4: var evens = numbers.Where(num => num % 2 == 0);
As of .NET 3.5, predicates are typically represented as Func<T, bool> where T is the type of the item to examine. Previous to .NET 3.5, there was a Predicate<T> type that tended to be used (which we’ll discuss next week) and is still supported, but most developers recommend using Func<T, bool> now, as it prevents confusion with overloads that accept unary predicates and binary predicates, etc.:
1: // this seems more confusing as an overload set, because of Predicate vs Func
2: public static SomeMethod(Predicate<int> unaryPredicate) { }
3: public static SomeMethod(Func<int, int, bool> binaryPredicate) { }
4:
5: // this seems more consistent as an overload set, since just uses Func
6: public static SomeMethod(Func<int, bool> unaryPredicate) { }
7: public static SomeMethod(Func<int, int, bool> binaryPredicate) { }
Also, even though Predicate<T> and Func<T, bool> match the same signatures, they are separate types! Thus you cannot assign a Predicate<T> instance to a Func<T, bool> instance and vice versa:
1: // the same method, lambda expression, etc can be assigned to both
2: Predicate<int> isEven = i => (i % 2) == 0;
3: Func<int, bool> alsoIsEven = i => (i % 2) == 0;
4:
5: // but the delegate instances cannot be directly assigned, strongly typed!
6: // ERROR: cannot convert type...
7: isEven = alsoIsEven;
8:
9: // however, you can assign by wrapping in a new instance:
10: isEven = new Predicate<int>(alsoIsEven);
11: alsoIsEven = new Func<int, bool>(isEven);
So, the general advice that seems to come from most developers is that Predicate<T> is still supported, but we should use Func<T, bool> for consistency in .NET 3.5 and above.
Sidebar: Func as a Generator for
Unit Testing
One area of difficulty in
unit testing can be
unit testing code that is based on time of day. We’d still want to
unit test our code to make sure the logic is accurate, but we don’t want the results of our
unit tests to be dependent on the time they are run.
One way (of many) around this is to create an internal generator that will produce the “current” time of day. This would default to returning result from DateTime.Now (or some other method), but we could inject specific times for our
unit testing. Generators are typically methods that return (generate) a value for use in a class/method.
For example, say we are creating a CacheItem<T> class that represents an item in the cache, and we want to make sure the item shows as expired if the age is more than 30 seconds. Such a class could look like:
1: // responsible for maintaining an item of type T in the cache
2: public sealed class CacheItem<T>
3: {
4: // helper method that returns the current time
5: private static Func<DateTime> _timeGenerator = () => DateTime.Now;
6:
7: // allows internal access to the time generator
8: internal static Func<DateTime> TimeGenerator
9: {
10: get { return _timeGenerator; }
11: set { _timeGenerator = value; }
12: }
13:
14: // time the item was cached
15: public DateTime CachedTime { get; private set; }
16:
17: // the item cached
18: public T Value { get; private set; }
19:
20: // item is expired if older than 30 seconds
21: public bool IsExpired
22: {
23: get { return _timeGenerator() - CachedTime > TimeSpan.FromSeconds(30.0); }
24: }
25:
26: // creates the new cached item, setting cached time to "current" time
27: public CacheItem(T value)
28: {
29: Value = value;
30: CachedTime = _timeGenerator();
31: }
32: }
Then, we can use this construct to
unit test our CacheItem<T> without any time dependencies:
1: var baseTime = DateTime.Now;
2:
3: // start with current time stored above (so doesn't drift)
4: CacheItem<int>.TimeGenerator = () => baseTime;
5:
6: var target = new CacheItem<int>(13);
7:
8: // now add 15 seconds, should still be non-expired
9: CacheItem<int>.TimeGenerator = () => baseTime.AddSeconds(15);
10:
11: Assert.IsFalse(target.IsExpired);
12:
13: // now add 31 seconds, should now be expired
14: CacheItem<int>.TimeGenerator = () => baseTime.AddSeconds(31);
15:
16: Assert.IsTrue(target.IsExpired);
Now we can
unit test for 1 second before, 1 second after, 1 millisecond before, 1 day after, etc. Func delegates can be a handy tool for this type of value generation to support more testable code.
Summary
Generic delegates give us a lot of power to make truly generic algorithms and classes. The Func family of delegates is a great way to be able to specify functions to calculate a result based on 0-16 arguments.
Stay tuned in the weeks that follow for other generic delegates in the .NET Framework!
Tweet
Technorati Tags: .NET, C#, CSharp, Little Wonders, Generics, Func, Delegates
