Skip to main content

Duck Typing with Anonymous Types - Part 2

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.Method.Name);
            invocation.ReturnValue = method.DynamicInvoke(invocation.Arguments);
        }
    }

    [... snip ...]

    private Delegate GetMethod(string name)
    {
        return anonymous.GetPropertyValue(name) as Delegate;
    }
}
[Test]
public void CanInvokeMethod()
{
    var duck = new
    {
        Color = "white",
        Quack = (Func<string>)(() => "Quack!")
    };

    var typedDuck = duck.As<IDuck>();

    Assert.That("Quack!" == typedDuck.Quack());
}

It works! Now... what about overloads? This is a bit trickier. We can start by deciding that overloads will be stored as an array of System.Delegates.

[Test]
public void CanInvokeOverloadedMethods()
{
    var launchPad = new
    {
        Fly = new Delegate[]
        {
            (Func<Direction>)(() => Direction.West),
            (Func<Direction, Direction>)(d => d)
        }
    };

    var launchPadMcQuack = launchPad.As<IDuck>();

    Assert.That(Direction.West == launchPadMcQuack.Fly());
    Assert.That(Direction.South == launchPadMcQuack.Fly(Direction.South));
}

A modified GetMethod method in our interceptor allows the test to pass.

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.GetParameters().Count() == invocation.Arguments.Count()).First();
}

This is obviously a naive implementation - overload resolution is extremely difficult. This will fail for overloads with the same number of parameters differentiated by type, methods with the params keyword, and methods with out/ref parameters. For now, though, we have something that will work well for very simple interfaces. In my final post, I'll try to make the overload resolution a little smarter and handle one other scenario I haven't talked about - indexed properties.

Comments

Popular posts from this blog

Who I'm Is

I am a junior .NET developer currently working in Chicago, IL. I am starting this blog in order to enhance my knowledge of programming subject matter. Hopefully, someone else will be helped along the way. This first post will probably be edited soon...

Stubbing Static Methods with PostSharp

TypeMock uses the Profiler API to allow mocking, stubbing, etc. of classes used by code under test. It has the ability to handle sealed classes, static classes, non-virtual methods, and other troublesome-yet-oft-encountered scenarios in the world of unit testing. Other frameworks rely on proxies to intercept method calls, limiting them to be able to only fake virtual, abstract, and interface members. They also rely on dependecy injection to place the proxies as the concrete implementation of calls to the abstracted interface members. Anyone working with a legacy codebase is bound to run into static method calls (especially in the data access layer), dependencies on concrete types with non-virtual methods, and sealed class dependencies (HttpContext anyone?). The only way to unit test this without refactoring is with TypeMock. I've never used TypeMock, and I'm sure it's a great product, but it's not free. I decided to spike some code to see if I could solve the prob...

Strongly-Typed Property Constraints in Rhino Mocks

UPDATE: As I suspected, this functionality was right in front of my face – it’s called PredicateConstraint in Rhino Mocks. I also realize that I managed to completely ignore the existence of Predicate<T> in the framework, and write my own predicate delegate. Hey, I was on a roll. Rhino Mocks has a PropertyConstraint class that allows you to check the values on properties of objects passed into the method as part of the verification for that method being called. Unfortunately, the name of the property is specified as a string, which means the benefits of strong-typing that Rhino Mocks is normally so good at preserving are lost. Here’s an example (using Rhino Mocks 3.3 and .NET 2.0): [Test] public void Main_Form_Should_Show_Start_Panel_On_Load() { MockRepository mockRepository = new MockRepository(); IMainFormView mockView = mockRepository.DynamicMock<IMainFormView>(); IEventRaiser loadEventRaiser = GetEventRaiserFor(delegate { mockView.Load += null; });...