I was just about to write the second blog post of the series, this time involving currying, the forward pipe operator and other functional programming beauties when two people discouraged me from doing it. First Mike from the WinForms team kindly implied that with functional C# programming I can get some permanent brain damages and I definitely won't keep my audience concentrated. Then came Joe Zydeco's comment to my previous blog post and I gave up. I don't know why people don't like functional C# programming but point taken, no more functional C# in my blog posts (for those of you who like it, you could check this page).
Maybe I need to clarify that the purpose of the series of these blog posts is not to save a few lines of code at any cost. In fact in some blog posts it may look quite the opposite as my preferred choice could contain more lines of code than the most compact solution.
Then comes the question "Ok, and how exactly are we saving a few lines of code?". The answer would be that you've written more lines of code today but in the long term you may find out that you've chosen the better option and that leads to less code in the future when you need to change your existing code. The "better option" could be somewhat ambiguous but at lest for me it takes into consideration concepts like readability, maintainability and extensibility.
For example today's post is dedicated to the way you're doing reflection. Typically the most common thing to do when dealing with reflection is to get a FieldInfo, PropertyInfo or a MethodInfo by doing the following:
| MethodInfo method = typeof(Class1).GetMethod("Method1"); |
One line of code could hardly be optimized so we should start looking for other ways to make it better. And this could be done better by trying to make the reference to the "Method1" method statically typed. This will save us a lot of effort and, of course lines of code, if later you decide to rename Method1 to something else.
Again I've prepared a sample project with a helper class which thanks to lambda expressions allows you to get a field, property or method info in a statically typed manner.
e.g.
| Reflect.Method<Class1>(x => x.Method1()); |
| Reflect.Property<Class1>(x => x.Property1); |
| ... |
I've used Daniel Cazzulino's implementation as a base and made a few changes. Actually lambda expressions are not mandatory in this case even though they improve the syntax quite a lot. Oren Eini has done a similar implementation for .NET 2.0 by using generic delegates back in 2005.
Although this approach looks pretty good I think I should mention its drawbacks. The first drawback is that you need to reference the assembly which contains the reflected type and the second drawback is that you can't reflect private and internal fields, methods and properties.
Anyway if these drawbacks do not apply to your scenario, statically typed reflections could save a lot of headache.