C# techniques: simulating stack unwinding and block syntax

One of my favorite things about C++ was its predictable stack unwinding.  This could be combined with anonymous scopes for some powerful techniques.  (I learned all about this from Steve) For example, I might want to hold onto a lock to something for a particular time.  I could simply make an object which allocates the lock in its constructor and releases it in its destructor.

// Anonymous scope for lock
{
ResourceLock lock;
//…
}

ResourceLock allocates the resource it its constructor. It lives on the stack until the local block is exited, whereupon its destructor is called and the lock is released.

The really great thing about this technique, especially for things like locks, is that it’s entirely exception safe. Can we do something similar in C#?

Method 1: IDisposable/using
The C# way of doing predictable allocation is IDisposable. And since we have a bit of syntax sugar in the ‘using’ block to make it exception safe, we may as well use it for this purpose.

class ResourceLock: IDisposable
{
public ResourceLock()
{
// allocate the lock
}

public Dispose()
{
// release the lock
}
}

// usage example
using(new ResourceLock())
{
// the lock is held here…
}
// … and released here

Hopefully the usage is pretty obvious. I like this method because the usage syntax is pretty good. In fact I don’t know of another method for things like locks. But there are other scenarios where you might want to do a bit more.

Method 2: Delegate passing
You’ll be familiar with this technique if you’ve ever used Ruby or Smalltalk. Those languages (and others) have native support for blocks. It’s not quite as nice in C# but still usable.

Let’s take the example of data binding. There are often cases where you need to do a batch of operations on a class which can throw change events. While it’s not strictly incorrect to throw an event after each operation, it can be a big performance problem. So we want disable change notification while the operations are in progress and throw a single change event when they’re done. Think of it as a kind of data-binding transaction.

We’ll implement the Transaction method using a Delegate parameter:

// A class which is observable in some way
class DataBindingClass
{
    public void Transaction(Action a)
    {
        try
        {
            SuspendChangeNotification();
            a();
        }
        finally
        {
            ResumeChangeNotification();
            NotifyObserversOfChange();
        }
    }
}

By passing an anonymous delegate to this method, we get an acceptable (but not great) syntax.

public void DoStuff(DataBindingClass db)
{
    db.Transaction(delegate() 
    {
        // do some stuff
    });
}

Don’t forget that you can pull in variables from the surrounding scope via closure. That’s really the only reason this technique is worth bothering with.

Method 3: IEnumerable/yield return/continuations
Okay, we’ve now stepped clearly into the realm of abuse. Please don’t do this in your code. But in the interest of completeness…

Since the yield return syntax is really a form of continuation, we can get the same general scoping effect with a little bit of creativity.

// A class which is observable in some way
class DataBindingClass
{
    public IEnumerable<int> Transaction()
    {
        try
        {
            SuspendChangeNotification();
            yield return 42;
        }
        finally
        {
            ResumeChangeNotification();
            NotifyObserversOfChange();
        }
    }
}

// usage example
public void DoStuff(DataBindingClass db)
{
    foreach(var i in db.Transaction())
    {
        // do some stuff
    }
}

As you can see, we abuse the ability of foreach to iterate over any IEnumerable to simulate a block syntax. In this case the block is only called once, so the loop only runs one time. The particular value we yield out Transaction() is completely arbitrary, as is the type. It’s only there to fool the loop into running.

In summary
C# gives us some reasonable tools here. I recommend method 2 (delegate passing) for most cases – it’s very flexible and the syntax is reasonable.

Advertisements

Trick-hot command pattern in C#

I’m working on some code that needs an undo feature, so naturally I turned to the command pattern.  I pulled out GoF to glance at their naming conventions and started to type, all the while thinking “there has to be a better way to do this.” Here’s what I think is a better way.

Recall that the command pattern specifies an abstract “Command” type with an Exceute method. This is only needed in languages without first-class functions: C# gives us delegates, which are pretty much equivalent in this case.  So we’ll skip the custom class and just use them.

But the extended, more useful form of the pattern also has an UnExecute method, used for undo.  This lets you push the commands onto a stack after executing them.  Undo is then simply a matter of popping the most recent command off the stack and UnExecute()ing it.  The command instance retains enough state information to undo what it had previously done.

We can do all that through the clever application of closures.  I’ve chosen to implement the commands as static methods, but they could also be implemented as regular methods, even virtual if you’d like to be able to route around to different implementations. Here’s a fictitious example:

static class Commands
{
    public static Action HAlign(Item stationary, Item movable)
    {
        int oldX = movable.X;
        movable.X = stationary.X;

        return delegate()
        {
            movable.X = oldX;
        };
    }
}

Executing the command is just a method call, and enabling undo is as simple as pushing the returned Action (just a delegate with no parameters or return type) onto an undo stack. (Stack<Action> will do nicely) The returned delegate captures, via closure, all the state in needs for undo to work properly.

That’s it! There are a few small land-mines in the details of how closures work (especially w.r.t. non-local or iteration variables), but the general technique is very simple.

My Bookshelf

These are the books I have at work, which mostly reflect the various projects I’ve worked on over the years.  Some are useful, some are not.

General Books:

  1. Design Patterns, GoF: Recommended, but first read Head First Design Patterns.  These two books togther kicked my brain into being able to think critically about design decisions.
  2. The Pragmatic Programmer:  I like it, though I think it’s worth less now in the light of robust discussion of these topics on blogs.
  3. Peer Reviews In Software: Haven’t opened it.  Got it from a mandatory training class that didn’t impress me.
  4. Lean Software Development / Implementing Lean Software Development: Barely cracked them. Put on my desk by my boss, but I think this particular movement (in our organization, anyway) is going to pass before I need to care too much about it.
  5. Extreme Programming Explained: Barely cracked, though I bought it myself.  Once I started reading it, I realized I already learned the content on the web.

Technology-specific books:

  1.  The C++ Programming Lanuage: Essential if you’re using the language.
  2. Effective C++/More Effective C++/Effective STL: Also essential if you’re using the language.  Other books tell you how to write code, but these books tell you how to right GOOD code.
  3. Effective C#: Doesn’t live up to its namesake.  Perhaps there are fewer gotchas in C#?
  4. Java Performance Tuning: I got this for $5 and learned one or two things from it.  But I think it’s about Java 1.1, so it’s more than a little out of date.
  5. Interprocess Communication in Linux: useful when I needed it, but I no longer need it.
  6. Programming .Net components: This is a bit of a weird one.  I was hoping it would explain the mysterious System.ComponentModel namespace, but I never got into it enough to fully understand what’s going on.  I could probably learn a lot from this book if I got into it, but I’m not motivated to do it anymore.
  7. Java development with Ant: I like this one.  Useful whenever I need to do ant, which is more often than one might think.  And my copy is autographed!
  8. Applications=Code+Markup: Meh.  Not that impressed.  If you want a WPF book, get:
  9. Windows Presentation Foundation Unleashed: This is the one you want.  It’s smaller than the previous book, but it has better explanations about the things that matter.
  10. Debugging Microsoft .NET 2.0 Applications: This book has saved my ass on multiple occasions.  If you’re developing for .NET, you need to know how to use your debugging tools.

What does your bookshelf look like?  Are there any bacon-saving books you’d recommend?

On the Abuse of IEnumerable

If it’s worth doing, it’s worth overdoing!

The abuse context in this case is the IEnumerable interface and the new (in C# 2.0) ‘yield’ statement that goes with it. In case you don’t know, it’s a trick hot feature that lets you easily return a sequence of things without having to create a temporary object. I like to think of it as being ‘foreachable’. Typical uses of this simply iterate over a single list. I’m going to show you to traverse a tree.

By way of example, lets start with the tree structure we used in the last article:

class Node {  
    Node[] children;  
}

Let’s throw things up a little this time and look at the client code first. What I want to be able to do is traverse over the tree as transparently as possible. We got pretty close last time, but this method will be better:

void TestTraversal()
{
    Node root = GenerateTestTree();

    int nodeCount = 0;
    foreach(Node n in root.Traverse)
    {
        nodeCount++;
    }
}

This is my favorite kind of source code – it’s absolutely obvious what’s going on, with no indication of what needs to happen inside. Perhaps ‘Traverse’ could be a better name, though: ‘Nodes’, or something. But you get the idea.

To implement this, we’ll use an IEnumerable (foreach-able) property:

class Node {
    public Node[] children;

    public IEnumerable<Node> Traverse
    {
        get 
        {
            foreach(Node child in children)
                foreach(Node n in child.Traverse)
                    yield return n;

            yield return this;
        }
    }
}

This is the meat, and it bears further study. The two nested loops are the recursive step, with a twist: they must re-yield each child’s result up to the caller. This is hard to grasp at first. It may help to note that a more sensible way of saying the same thing would be:

// THIS WON'T BUILD!!!
foreach(Node child in children)
    yield return child.Traverse;

That is, in fact, what I tried to write the first time I did this. But you can’t yield anything to an IEnumerable but its defined type. This is clearly a design flaw in the C# language. The workaround for this is to iterate over the child and re-yield each item.

I have mixed feelings about this technique. Between it and the delegate vistor technique I wrote about previously, it’s really hard to say what’s better. For applications where clarity of implementation is most important, I lean towards the delegate version. It’s easy to explain to anybody who understand function pointers, which is most people.

But for applications where a good API is the most important, I like the IEnumerable version (this one). It’s as clean as an API can possibly be, and it retains all the run-time benefist of the visitor pattern: it uses no temporary storage, and the user’s code is run once at every node instead of stringing all the calls together at the end.

Delegates and Visitors

The GoF visitor pattern is useful but awkward. The usual c++ or Java-y versions typically involve some kind of visitor interface which your visitor must subclass. Java somewhat mitigates this with anonymous classes, but not fully. In C#, if we’re clever with the use of delegates, we can make tasks like tree traversal look about as simple as iteration.

Let’s start with a simple tree class:

class Node {
    Node[] children;
}

We’ll implement a depth-first search using the visitor pattern. Using delegates, we can eliminate the need for an additional class:

class Node {
    public Node[] children;

    public delegate void VisitorDelegate(Node currentNode);
    public void Traverse(VisitorDelegate visitor)
    {
        foreach(Node n in children)
        {
            Traverse(n);
        }
        visitor(this);
    }
}

This is a pretty simple recursion, and really isn’t anything special. The way delegates are typically used, there is still an additional method required for the delegate to be called. But with C# 2.0, we have the opportunity to use anonymous delegates. This is where we can write some really slick code:

void TestTraversal()
{
    Node root = GenerateTestTree();

    int nodeCount = 0;
    root.Traverse(delegate(Node n)
    {
        nodeCount++;
    });
}

The really cool thing about this is that, since anonymous delegates can act as closures, our visitor can pull in the nodeCount from the surrounding environment. This makes for a very succinct version of the visitor pattern.

Technorati Tags: ,

Properly Abstracted List APIs (in C#)

We frequently encounter APIs that take lists of objects as parameters. The code behind the API will likely want to know something about those objects. It might sort them or extract some metadata and then process them. It may return a list of the objects with additional data. The question at hand is: how should the API get the data it needs about those objects?

Presented below is an elegant solution which preserves separation of concerns.

In considering this problem, we’ll use a simple (read: contrived) example: a chart drawing API that needs an X and Y data point for each item in the chart. The client has a number of StockQuote objects it wishes to plot, defined as follows:

class StockQuote
{
    public float price;
    public DateTime date;
}

Suppose further that later on I want to be able to react to user interaction with the chart and obtain the relevant StockQuote object.

Simple Approach: Data Objects
A typical approach would be to define a data structure with the information in question. For example:

library:

class ChartPoint
{
    int objectId;
    public int x, y;
}

Chart CreateChart(List<ChartPoint> points);

client:

List<ChartPoint> points = new List<ChartPoint>();
foreach(StockQuote quote in quotes)
{
    points.add(new ChartPoint(quotes.IndexOf(quote),
        quote.date.DayOfYear,
        quote.price));
}

CreateChart(points);

This works, and is explicit, but is very wordy. It’s very easy to implement on the library side, of course. But I’ve got to create an intermediate list of this other type on the client side, which adds three lines of additional code on top of the call, plus an intermediate list. It also imposes this requirement that I have an Id to refer to my object, so I can know which one is which when later interacting with the chart. That’ll be another layer of lookup – this doesn’t feel right at all.

OO-Approach: Interfaces
Many would suggest the following method:

library:

interface IChartable
{
    public int X { get; }
    public int Y { get; }
}
Chart CreateChart(List<IChartable> points);

client:

class StockQuote : IChartable
{
    public float price;
    public DateTime date;

    public int X { get { ... } }
    public int Y { get { ... } }
}

ChartAPI.CreateChart(stockQuotes);

The actual invocation has improved, and I no longer need the Id field, since I’m passing in my objects directly. But now my class has to implement this ‘chartable’ interface that none of the rest of the code actually cares about. That doesn’t feel right either. We should be able to do better.

Generic Approach: Accessor Delegates
The question to ask is: what is the fundamental thing the library actually cares about? What is the core of the problem? The answer in this case is: for each object, what is the X value and what is the Y value? Or to phrase it differently: how I extract the values from the object in question? Lets provide that information directly.

library:

delegate int CoordinateAccessDelegate(object o);
Chart CreateChart(List<object> items,
    CoordinateAccessDelegate xAccess,
    CoordinateAccessDelegate yAccess);

client:

ChartAPI.CreateChart(quotes,
    delegate(StockQuote q) { return q.date.DayOfYear; },
    delegate(StockQuote q) { return q.date.price; } );

Since what we want is the way to access the X and Y data, we’ll give it exactly that: an access delegate. In this way, the chart library doesn’t particularly care about the format of the data I’m using, nor does the rest of my application care about the requirements of the chart library. And I avoid the painful copy step of the data-centric version.

A hidden benefit of this approach is revealed later, when the chart library needs to return to me information about some user interaction. It can do this now in my own terms, with my own objects, rather than by using some structure with an id field that I have to map to my object.

Some will have correctly observed by now that this is the same technique used to provide a sort comparator. This is exactly right! Understanding the technique and realizing it may be used elsewhere is the entire point.

Of course, this technique is not appropriate for all problems. If a large number of accessors are required, it probably shouldn’t be used. The goal is a literate API, one in which the invocation parameters represent the data that is actually required.

Technorati Tags: , <a

Standard is Better than Better

Neal Ford wrote some interesting things about naming conventions: Eating Sacred Hamburger. And even though I agree with everything he says, I think he draws the wrong conclusions.

He first argues the relative merits of various naming conventions, preferring ruby_case to CamelCase, especially for very_long_and_drawn_out_method_names. It think he hits it right on the button, though I personally prefer lisp-case for very-long-and-drawn-out-method-names, since it’s easier to type.

He also argues against Hungarian notation, which I agree is a blight upon all that is good and green. And the IInterface notation is also a little silly, but…

It’s convention. We should follow the convention.

Did I just say that? Giving up progress, and readable code, just to do it in the same way it’s always been done?

Well, yes. Remember in C++, when you were using STL sometimes and MFC sometimes? They used different naming conventions entirely. And you could never remember what goes with what. Intellisense helps with that some, but it’s still awkward. And what about reading the code? While it may be a little clumsy to read long names in camel case, it’s far better to have the formatting match. The overall codebase is more beautiful as a result.

So, I say: bring on the IInterfaces! At the end of the day, I don’t care how we name things as long as we name them the same way. Or, to quote my boss: “standard is better than better.”

(Maybe they got rid of Hungarian notation not because it sucks (which it does), but because they couldn’t get everybody to agree on it. A convention is only useful if everybody does it. And right now, in C# at least, everybody does do it. It’s great for an old C++ hacker like me. So please, don’t break it!)

Technorati Tags: , ,