Doing dynamic programming is all the rage these days. Some of the biggest proponents seem to be those that practice TDD. To that style of development, everything is fair game and dependency injection is used to solve many issues. Those injections are usually based on some reference to a provider of some sort. Others, caught in the declarative world of modern databinding are using named properties of objects.
Both worlds have need of the ability to link up the desired behavior, and they usually accomplish it through string constants that point at the desired provider or property. This is where one of my oldest code-smells kicks in; you can't dependency-check a string constant very well. The TDDers will tell you, "No problem, Mon! The tests will catch that." Old hackers like me don't want to wait that long (and that's one of the reasons type-less languages have so little appeal to me). We want something that will catch the errors for us immediately. Using things like Visual Assist's red-squiggle, the compiler's error messages, or even the IDE's cool automatic scoped rename ability keeps me from having to even run the test to catch the stupids.
So back to the string constants. How do we get the compiler/IDE to understand the connection? By making it a code link, of course. We want to replace those string literals with actual references, in some form, to the actual property or provider. This isn't a new problem, so it should come as no surprise that it's been tackled a couple of times recently for .Net development.
Let us study a couple examples and be us I mean you, I've finished my homework.
The wrong way: Get rid of nasty "string"
The right way: Static Reflection
Okay, are you back now? I'll wait, really...
What I don't like about the first idea is that it reads HORRIBLY. The code's intent is completely non-obvious, it creates all kinds of proxies where none are needed. It's ugly. Ayende's solution works without making any significant objects at runtime. The whole thing is just compiled away into a single delegate which will likely get optimized out of existance anyway.
What's the moral? If the code you are replacing is much easier to understand and maintain than the code you are using instead... you are not done refactoring.
Update: Of course this breaks down at pointing to properties because C# is overprotective, read the comments for the best-until-they-lighten-up-at-C#-land.