Development Central

“…an interface with one method is just a delegate…”

Sheer brilliance.

Mark Rendle said that on a Herding Code podcast. The context was that interfaces in APIs require that callers reference an assembly containing the interface definitions, and that versioning issues arise. A functional approach has the potential for avoiding those issues.

It’s a different way of looking at things. I wonder if he’s played Portal?

Some very smart people have balked at the idea of prefixing C# interfaces with the letter “I". While I dislike Hungarian notation, I am in favor of IInterfaces.

My main reason is the C# language itself. Consider this code:

public class Employee : Person

Is Person an interface or a class? Proponents of the no-I convention might say that it shouldn’t matter. In C#, though, it does matter. In a single-inheritance language, you only get one base class. Also, if I want to see all of the behavior for Employee, I may want to look at the code for Person as well if it’s a class.

Java has the implements and extends keywords; C# only has the colon (:). In Java you can identify interfaces at a glance; in C# you can’t.

My other reason is that it’s the standard. Microsoft’s conventions say to prefix interface names with the letter I. Most of the C# code I’ve seen does. Deviating from this convention can confuse developers.

I hope we can see eye to I on this.

I have upgraded the Singleton Pattern from Evil to Mostly Evil. Last week I actually found a valid use case for it.

I had a class that used the Strategy Pattern; a constructor parameter was an interface with a method for the algorithm. An IoC Container would have been overkill here; this was in a library module, and the class was only used by one other class in the library. That instantiated it twice, once for each of two algorithms (two strategies, each implementing the interface). The calling class had to know which algorithm to use each time.

The algorithms were pretty simple, and had no state. They were a little too complex for a lambda, though.

So I used Lazy<T> to make the strategies/algorithms Singletons, giving each a static Instance property that returned a lazy-created instance. (As an aside, if you make the constructor private you have to specify a lambda/delegate to Lazy or you’ll get a runtime exception.) I sealed the strategies to be safe.

If this seems like a very narrow use case to you, it does to me, too. But, if the stars align, you may be able to use the Singleton Pattern safely too. Hopefully without summoning the Great Old Ones*.

* - Some say Azathoth is itself a Singleton…

The Moq mocking library only gets better. Here’s a LINQPad example of the functional specifications introduced in v4.

void Main()
{
    var foo = Mock.Of<IFoo>(f =>
        f.Id == 1 &&
        f.Who == "me" &&
        f.GetBar(It.IsAny<string>()) == Mock.Of<IBar>(
            b => b.Name == "Fred"));

    Console.WriteLine(foo.Id);
    Console.WriteLine(foo.Who);
    Console.WriteLine(foo.GetBar("whatever").Name);

    // If you need verification and still want to use
    // the functional style:
    Mock.Get(foo).Verify(f => f.GetBar("whatever"));
}

public interface IFoo
{
    int Id { get; }
    string Who { get; }
    IBar GetBar(string name);
}

public interface IBar
{
    string Name { get; }
}

This prints:

1
me
Fred

No more having to type "mock.Object"!

For more details, see Old style imperative mocks vs moq functional specifications and this Moq Discussions thread. Note that Daniel Cazzulino (kzu) suggests separating behavior-verification mocks and stubs; this syntax is most useful for stubbing.

Today was a really productive day. I’ve been doing a lot of analysis lately and too little coding. Today I worked on a task that I thought would be (a) time-consuming and (b) difficult to test. It turned out to be neither.

Test-first development and LINQ made my day! :)