Mike Moore raised a good question on my previous post about (ab)using anonymous delegates to achieve JavaScript-like dynamic class interface  functionality:

You can swap out the expected return value when using this for testing, but can you actually implement any useful, state-changing functionality using anon delegates?

So I decided to try this out and I was able to do most of what he's asking for, with one caveat.

Member Accessibility Rules Still Apply

First, I should say that the rules of member visibility still apply with respect to accessing, for example, private member variables from an external caller. That is, if you 'override' one of the anonymous delegate pseudo-methods from outside the class definition itself, you will not be able to access the private member variables inside that class.

Consider the following class:

public class WellWaterSource : WaterSource
{
    private bool _isDrought;

    public WellWaterSource()
    {
        TakeSome = () => { return !_isDrought; };
    }
}

If I want to override TakeSome on WellWaterSource from outside the WellWaterSource class definition, I won't be able to access the _isDrought member.  This will limit the amount of stuff you can do with this approach, for sure. So you would definitely want to avoid private members for sure, and internal and protected members would require serious consideration. For example:

public class SomeOtherClass
{
    public SomeOtherClass(WellWaterSource src)
    {
        src.TakeSome = () => { return true && src._isDrought; };
    }
}

This will result in a compiler error:

error CS0122: WellWaterSource._isDrought' is inaccessible due to its protection level

Accessing Instance Members From Class Prototype Requires Compromise

One other downside of this approach is that, in order for you to access instance members from the class-level prototype, you have to pass in the 'this' reference to the delegate.

Consider the following class:

public class SmallWellWaterSource : WellWaterSource
{
    public static WellTakeSomeFunc TakeSomeWellWaterPrototype =
        w => { w.WaterRemaining--; return (w.WaterRemaining > 0); };

    public int WaterRemaining { get; set; }

    public SmallWellWaterSource()
        : base()
    {
        WaterRemaining = 100;
        TakeSome = () => { return TakeSomeWellWaterPrototype(this); };
    }
}
public delegate bool WellTakeSomeFunc(SmallWellWaterSource source);

You'll notice that we have to pass in the 'this' reference in the c'tor in order to allow the static prototype to access/manipulate the WaterRemaining value. This isn't horrible, and would be a common pattern, but it's some extra work you have to do that you wouldn't (obviously) in other languages like JavaScript, Ruby, etc.

This isn't just .NET 3.5

Mike made a comment about not having .NET 3.5 installed yet. I just wanted to point out that none of this stuff is .NET 3.5-specific. You can do it with .NET 2.0, it's just uglier since we don't have lambda expressions. For example, we could do this:

public class WaterSource
{
    public static TakeSomeFunc TakeSomePrototype = delegate { return true; };

    public TakeSomeFunc TakeSome = delegate { return TakeSomePrototype(); };

    public delegate bool TakeSomeFunc();
}

Last Comment

Finally, Mike says:

All this work to get around static typing...

I know, man. I know. I can't use Ruby at work, though (heck, I can't even use .NET 3.5 at work yet), so we can at least try to explore how to bend C# to our will as much as possible :)