In Search of Lost Time

A few months ago I finished reading the second edition of Brad Abrams and Krzysztof Cwalina's excellent Framework Design Guidelines book. I just love how this book condenses the lessons learned in building the .Net Framework in areas such as design patterns and API usability into a set of easy to follow guidelines annotated by various luminaries from Microsoft and beyond.

For me reading the book provided valuable insight into .Net, reinforced my knowledge of design patterns and provided lots of useful advice on software engineering in general. As an example one guideline that I recall as I write this is do prefer protected accessibility over public accessibility for virtual members''. This leads to the suggestion of applying the template method pattern as follows:

1
2
3
4
5
6
7
8
9

public Control {
    public void SetBounds(...)
    {
        ...
        SetBoundsCore(...);
    }

    protected virtual void SetBoundsCore(...) { ... }
}

The book also makes the valuable point that this pattern allows the base class to enforce that overloads remain semantically consistent by defining them in the base class in terms of one core virtual method that can then be overriden.

On the usability front a comment from Krzysztof has stuck with me since reading the book:

The number of customers that will use your API is inversely proportional to the number of new statements in your simple scenarios.

This reinforces the book's suggestion of a scenario driven design approach where we are encouraged to write code for common scenarios before designing the API and run user studies early on with other developers writing code exercising these main scenarios.

Finally Framework Design Guidelines introduced me to FxCop which does the great job of encoding the guidelines in a static analysis tool thus catching any accidental slips in our APIs early on. This makes following a large number of the guidelines incredibly easy.

As Miguel de Icaza asserts in the foreword: this book will help you become a better programmer.

I was once asked in an interview what my favourite feature of C++ was to which I immediately responded "destructors". The interviewer retorted that garbage collection made destructors redundant. Looking back I assume that he was pushing me to give further explanation of what made destructors such a neat feature which I didn't manage to give immediately but I did explain in the context of boost::mutex::scoped_lock later on.

Lately working with C# has brought me back to the feeling that deterministic destruction is a great feature. In C# resources are destroyed using the dispose pattern

1
2
3
4
5
6
7
8
9

MyConnection connection = null;
try {
    connection = new MyConnection(foo);
    connection.Open();
    // Make use of the connection here
} finally {
    // Only today I encountered code where the null check was forgotten :(
    if (connection != null) { connection.Dispose(); }
}

this is made significantly less painful by the using keyword:

1
2
3
4

using (var connection = new MyConnection(foo)) {
    connection.Open();
    // Use connection here, disposed when we leave the using block
}

but it still relies on the caller to remember that instances of this class need special attention. In addition when there are multiple resources in use things can get a little messy (although nothing compared to Java which lacks the using keyword).

Back in the C++ world things are much simpler:

1
2

MyConnection connection(foo);
// use connection here, it will be destroyed when it goes out of scope

and this same pattern applies to all resources: files, memory, mutex locks, whatever. Not to mention the fact that it scales well to multiple objects. There is just something inherently elegant about solving the general case of resource management with one technique rather than the combination of garbage collection and the lock and using keywords.

I have just finished reading through Trey Nash's Accelerated C# 2008 and have found it a useful and enjoyable read. I picked it up at a local book shop some time ago as it seemed to be one of the few books covering C# 3.0 at the time and I didn't see the point in using anything older when approaching the language as new. I considered Pro C# 2008 and the .NET 3.5 Framework as an alternative but at over 1300 pages it seemed a little heavyweight and I was keen to read about just the core language and pick the other stuff up as I went along.

As a C++ programmer the book seemed to be targeted exactly at me with constant reference to that language and discussion of the merits of RAII in C++ compared with the IDisposable interface and the using statement in C#. Starting with an overview of C#, the CLR and basic syntax the book moves at a comfortable pace through strings, collections, iterators, delegates, generics and threading before taking a moment to search for "C# canonical forms". The book then turns its attention to extension methods, lambda functions and culminates in an introduction to LINQ. Although somewhat repetitive at times the book gives a good overview of the language with lots of useful references and even demonstrates implementations of some design patterns in C#.

I was however surprised at some of the design advice given especially the insistence on making classes 'sealed' unless you can think of a very good reason not to. This seems especially strange as the book references the Framework Design Guidelines, which make the opposite recommendation, on the same page. Although I do agree on favouring composition over inheritance.

While working through the book I have been playing with Monodevelop 2.0 which I built from svn along with the new(ish) Mono 2.0. I must say I'm impressed; it even has vi mode! I also like the fact that NUnit is integrated into the IDE.

I plan to continue my adventure into C# with the second edition of Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries when it arrives in the UK Amazon store next month.