Why on earth would you want to do that?
True, true but I came across a problem a few days ago while designing a TDD unit test and this was the situation: a great number of these tests needed to query a collection of objects which contain XML strings which needed to be de serialized into different objects.
One thing that the test "knew" ahead of time was the type of the object and based of this type the collection needed to be queried accordingly... then I thought that I needed a "callback", just like in JavaScript when we pass executable code as an argument of a function? ... a callback, right? The same I needed here, for me to encapsulate all this mundane code into a helper function instead of writing this over an over in every test.
Passing a Func<T, TResult> as a parameter of a method
It is simple; take a look at the signature of my test helper function. This is the call back signature, and what I want it to do once it will be executed, in the LINQ colleciton.Where, is defined in the body of the unit test code and it is a validation predicate.
Note how the test method now calls this utility passing this "callback" delegate Func as a parameter.
With that little trick I managed to encapsulate all the utility code in one place and reuse it. All I needed to do was change the type of object that I wanted and the func delegate.
Overkill? Maybe, but I think that it makes cleaner code.
