06/04/11

Permalink 08:25:15 pm, by truewill Email , 66 words, 303 views   English (US)
Categories: C#, IoC, .NET, Design

Interfaces and delegates

“…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?

05/29/11

Permalink 06:44:07 pm, by truewill Email , 174 words, 371 views   English (US)
Categories: C#, .NET

I is for Interface

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.

05/21/11

Permalink 10:30:32 pm, by truewill Email , 219 words, 208 views   English (US)
Categories: C#, IoC, .NET, Design

Singleton: Mostly Evil

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…

04/20/11

Permalink 08:08:08 pm, by truewill Email , 165 words, 604 views   English (US)
Categories: Tips, Testing, C#, IoC, .NET, Tools

Moq v4 functional specifications

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.

04/13/11

Permalink 08:17:41 pm, by truewill Email , 49 words, 245 views   English (US)
Categories: Testing, Agile, C#

Good day

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! :)

:: Next Page >>

Development Central

Development Central is the blog of Bill Sorensen, a professional software developer. Much of this will relate to C#, .NET, and OOP in general.

Disclaimer
These postings are provided "AS IS" with no warranties and confer no rights.

| Next >

Search

Categories

Linkblog

b2evolution

contributors

XML Feeds

What is RSS?

Who's Online?

  • Guest Users: 2

powered by b2evolution free blog software