Continuous Disintegration

A recent Daily WTF explored a Guard class which throws an ArgumentNullException if a parameter is null. Most of the commenters correctly point out that the code is not a WTF but rather a good practice because it Enforces the code contract - this parameter is not allowed to be null Provides better stack trace information Causes the app to fail fast One principle at work here is the idea of adding information to an exception. Without guarding against potentially invalid input in this situation, a NullReferenceException will (presumably) be thrown at some point. But why? What's null? What made it null? Even with the stack trace, this can be painful to debug... annoying at the least. An ArgumentNullException cuts straight to the problem and tells us exactly what is wrong. Anytime you can add information to an exception (or potential exception in this case), you should do it* . I think this is a good principle to follow when deciding whether or not to catch an exception (t...

Often when dealing with applications/systems that serve multiple clients, we encounter a situation where Clients share some core functionality and algorithms Clients have custom logic that extends the core functionality Clients have customized data structures that extend core data structures The key to making this work in a maintainable way (that is, without infusing the code with crazy branching statements or writing the whole application in dynamic SQL) is maintaining a distinct separation between core and client. Here I present components from a simple, hypothetical application that demonstrates such a separation. The application is meant to evaluate whether or not a client should acquire a player for fantasy football. It contains some core functionality for doing the evaluation (it doesn't pick up a player who has never scored a point) and a core data structure that represents a player. There are two clients who extend this core functionality: me and a stupid ...

Continuing my short series , it's time to add some polish to what we have so far. Overload Resolution At first I thought overload resolution was going to be a huge pain, but really the compiler does everything for us. As long as we have assigned an implementation with exactly matching parameters for the method that the compiler calls, we're good to go. The necessary modifications to the interceptor fit into a small reflection utility method. private Delegate GetMethod(IInvocation invocation) { var methodProperty = anonymous.GetPropertyValue(invocation.Method.Name); if (methodProperty is Delegate) { return methodProperty as Delegate; } var overloads = methodProperty as Delegate[]; return overloads.Where(m => m.Method.SignatureMatches(invocation.Method)).First(); } internal static bool SignatureMatches(this MethodInfo method, MethodInfo other) { var theseParameters = method.GetParameters(); var thoseParameters = other.GetParameters(); ...

Previously I looked at forwarding property calls of an interface to those of an anonymous type instance. Now I'd like to see if we can forward method calls as well. But how? We can't create an anonymous type instance with methods, and we can't assign assign anonymous methods as properties. This doesn't work: var duck = new { Color = "white", Quack = () => "Quack!" }; but this does: [Test] public void CanInvokeMethod() { var duck = new { Color = "white", Quack = (Func<string>)(() => "Quack!") }; } Let's modify our interceptor once again, this time to retrieve a delegate property named the same as the invoked method and invoke it. internal class DuckTypingInterceptor : IInterceptor { [... snip ...] public void Intercept(IInvocation invocation) { [... snip ...] if (invocation.IsMethodCall()) { var method = GetMethod(invocation.Metho...

If you can create an anonymous method and an anonymous type , why not an 'anonymous class'? Wouldn't it be nice to be able to plug properties and methods into and object and then consume that object like any other class or interface ? What we're talking about is essentially duck typing (with strongly-typed ducks). There are examples all over of how to do this, especially with Castle Dynamic Proxy. This is my implementation of the same. First let's look at a test: public interface IDuck { string Color { get; } Direction Fly(); Direction Fly(Direction direction); string Quack(); } [Test] public void CanStubColorProperty() { var rubberDuck = new { Color = "yellow" }; var typedRubberDuck = rubberDuck.As<IDuck>(); Assert.That(typedRubberDuck.Color == "yellow"); } That As<IDuck> part is an extension method that does nothing right now, so this test will fail. What we want that extensions method to do is to re...