Month: June 2006

For the last couple of months I’ve been using .NET 2 for the first time. There are a bunch of great new language features in there, generics being the most obvious (and implemented properly in .NET rather than the hack in Java), but another biggy is anonymous delegates.

One use of anonymous delegates is just to inline methods, e.g.:

public void MyFunkyExample()
{
Timer timer = new Timer();
timer.Elapsed += DoSomething;
timer.Interval = 1000;
timer.Start();
}

private void DoSomething(object sender, ElapsedEventArgs e)
{
Console.WriteLine("Hello World! (at {0})", e.SignalTime);
}

becomes:

public void MyFunkyExample()
{
Timer timer = new Timer();
timer.Elapsed += delegate (object sender, ElapsedEventArgs e)
{
Console.WriteLine("Hello World! (at {0})", e.SignalTime);
};
timer.Interval = 1000;
timer.Start();
}

This is handy occasionally when you have a 1 or 2 line method that only gets used as a delegate.

However, the real power of anonymous delegates comes when using them as closures. Take the following code as an example:

public void MyFunkyClosureExample()
{
string[] names = new string[] { "Fred", "Bob", "Sue" };
foreach (string name in names)
{
SetupTimer(name);
}
}

private void SetupTimer(string name)
{
NamedWriter writer = new NamedWriter(name);
Timer timer = new Timer();
timer.Elapsed += writer.Write;
timer.Interval = 1000;
timer.Start();
}

private class NamedWriter
{
private readonly string name;

public NamedWriter(string name)
{
this.name = name;
}

public void Write(object sender, ElapsedEventArgs e)
{
Console.WriteLine("Hello {0}! (at {1})", name, e.SignalTime);
}
}

Now we want to have several timers, but the event of each has different behaviour depending on some local value when the timer event is bound. Pre C# 2.0 you have to setup a custom class to handle this, but compare with the anonymous delegate version:

public void MyFunkyClosureExample()
{
string[] names = new string[] { "Fred", "Bob", "Sue" };
foreach (string name in names)
{
SetupTimer(name);
}
}

private void SetupTimer(string name)
{
Timer timer = new Timer();
timer.Elapsed += delegate(object sender, ElapsedEventArgs e)
{
Console.WriteLine("Hello {0}! (at {1})", name, e.SignalTime);
};
timer.Interval = 1000;
timer.Start();
}

This is much cleaner since we don’t need to introduce that custom class.

Using closures can get a little hairy, especially when you’re trying to figure out which value of variables actually get bound – check out one of Jeremy Stell-Smith’s recent entries on the subject. But of course, you’ll have plenty of automated tests to check what you’re doing, right? 😉

PS – apologies for the lack of decent formatting – I’m still getting to grips with WordPress.

Rebugging (verb) : The practice of refactoring without automated tests. Typically followed by a session of debugging.

🙂

I don’t normally blog about other people’s blog entries, but this is fascinating.

I’m a big fan of using a lot of delegation, with small methods and small classes, and I can understand when you’re sitting on a bunch of libraries that think the same way you can end up with these kind of stack traces.

Part of me wonders whether this is actually a problem. Modern IDE’s (e.g. IntelliJ, Resharper, Eclipse) make navigating abstracted delegation chains pretty easy (I’m forever pressing Ctrl(+Alt)+B or Ctrl+Alt+F7 in Resharper), and I would hope that the Managed VMs we use do clever stuff too. That said, I wouldn’t expect to have to understand library code more than a couple of calls outside of my own code, so libraries would have to make sure that their abstractions don’t leak too much.

Thanks to Simon Stewart for the link.

I’m putting together an ‘introduction to Agile’ presentation this week. I’ve done them before, but I like going back and writing these things from scratch since it allows me to think about what I’ve learned since the last time.

One thing I’ve added this time around is the first principle from the Agile Manifesto, which states:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

I’ve read this statement before, and even blogged about the business value slant it has, but I’ve never thought before how much overall it underpins everything I believe as an IT professional. Don’t tell anyone, but I don’t really care about test-driven development, stories, refactoring or even continuous integration. They’re just tools I use in order to fulfill the actual goal of delivering value early and often. At the moment they’re the best tools I know of for doing so, which is why I practice them, talk about them and even spend my own time writing open-source software to make some of them easier.

But they’re not the ‘axiom’ of why I do what I do. Getting useful, valuable, software in front of a real user; seeing the smile on their face when they see their professional lives are going to be easier (if that’s the value they gain); and having a conversation about what we can deliver next, and soon, is actually why I do what I do.

When I talked about this statement before, I focussed on the business value phrase, i.e. figuring out what the monetary benefit of a feature is. If you just take the word valuable as meaning ‘something which somebody values’, then this principle can be applied to any prospective customer in the business IT world.