C# 2.0 - Visitor return type

In this entry I'm revisting the Visitor Pattern, this time using C# 2.0 generics rather than Java generics. One addition to the previous design is to declare two interaces, one for a void return and one for a non-void return:

public interface IVisitable
{
    void Accept(IVisitor visitor);
    R    Accept(IVisitor1<R> visitor);
}
public interface IVisitor
{
    void Visit(A visited);
    void Visit(B visited);
    void Visit(C visited);
}
public interface IVisitor1<R>
{
    R Visit<R>(A visited);
    R Visit<R>(B visited);
    R Visit<R>(C visited);
}

Each concrete element then simply implements both Accept methods:

public class A : IVisitable
{
    ...
    public void Accept(Visitor visitor)
    {
       visitor.Visit(this);
    }
    public R Accept<R>(Visitor1<R> visitor)
    {
        return visitor.Visit(this);
    }
    ...
}

I could do this in Java too of course. However, the C# version edges out the Java version in two respects. First, C# allows two types to have the same name as long as they have a different number of generic arguments.

public interface IVisitor
{
    void Visit(A visited);
    void Visit(B visited);
    void Visit(C visited);
}
public interface IVisitor<R>
{
    R Visit<R>(A visited);
    R Visit<R>(B visited);
    R Visit<R>(C visited);
}

Secondly, generic IVisitor works with all types (including value types such as bool) without the need for wrapper classes:

public class ExampleVisitor : IVisitor<bool>
{
    public bool Visit(A visited) { ... }
    public bool Visit(B visited) { ... }
    public bool Visit(C visited) { ... }
}

Statement Refactoring

I've just noticed this somewhere:

public string MakeRequest(string hostname, string message)
{
    Socket socket = null;
    IPAddress serverAddress = null;
    IPEndPoint serverEndPoint = null;  
    byte[] sendBytes = null, bytesReceived = null;
    int bytesReceivedSize = -1, readSize = 4096;
    serverAddress = Dns.Resolve(hostname).AddressList[0];
    serverEndPoint = new IPEndPoint(serverAddress, 80);
    socket = new Socket(AddressFamily.InterNetwork,
    SocketType.Stream, ProtocolType.Tcp);
    bytesReceived = new byte[readSize];  
    sendBytes = Encoding.ASCII.GetBytes(message);
    socket.Connect(serverEndPoint); 
    socket.Send(sendBytes);
    bytesReceivedSize = socket.Receive(bytesReceived, readSize, 0);
    socket.Close();
    if(-1 != bytesReceivedSize)
    {
        return Encoding.ASCII.GetString(bytesReceived, 0, bytesReceivedSize);
    }
    return "";
}

Why do programmers still write code like this in C#? Do they like verbosity? Why not write this instead:

public string MakeRequest(string hostname, string message)
{
    IPAddress serverAddress = Dns.Resolve(hostname).AddressList[0];
    IPEndPoint serverEndPoint = new IPEndPoint(serverAddress, 80);
    Socket socket = new Socket(AddressFamily.InterNetwork,
                               SocketType.Stream, ProtocolType.Tcp);
    int readSize = 4096;
    byte[] bytesReceived = new byte[readSize];  
    byte[] sendBytes = Encoding.ASCII.GetBytes(message);
    ...
}

It seems to me there are loads of these statement level refactorings that would prove really useful. Do any tools support "small" refactoring like this? Do any books talk about them?

Here's another: Instead of writing:

if (expression)
    return true;
else
    return false;

why not just write:

return expression;

How Buildings Learn

I've been rereading How Buildings Learn by Stewart Brand. It's a really great read. It's author took the time and effort to do what few authors do. He didn't do the simple thing and just write about buildings at a certain point in time. He did the difficult thing and wrote about the underlying processes that govern the evolution of buildings over time.

At the heart of this book is the idea of change - of time. That buildings change. That people change them. That the elements change them. This, fundamentally, is the reason the parallels with software leap off every page. Understanding andmanaging change is arguably the fundamental aspect of understanding and managing the process of developing software. Software isn't written perfectly in a sudden flash.It takes time. It takes lots of small changes. The author writes "My approach is to examine buildings as a whole - not just whole in space, but whole in time". He laments the aphorism "Form ever follows function" written in 1896 by Louis Sullivan (A Chicago highrise designer) because "it misled a century ofarchitects into believing that they could really anticipate function". The idea is to aim for software that gets better over time. Or, more accurately,that is capable of getting better over time.

Here are some quotes:

Our basic argument is that there isn't such a thing as a building. A building properly conceived is several layers of longevity of built components.

Many buildings are demolished early if their outdated systems are too deeply embedded to replace easily.

Hummingbirds and flowers are quick, redwood trees slow, and whjole redwood forests even slower. Most interaction is within the same pace level.

The dynamics of the system will be dominated by the slow components. with the rapid components simply following along. Slow constrains quick; slow controls quick.

Trust, intimacy, intense use, and time are what made these buildings work so well.

Architects offered themselves as providers of instant solutions, and only the look of a building gives instant gratification.

Hackers and Painters

I've just finished reading Hackers and Painters by Paul Graham. It's a really excellent read which I highly recommend. Here are some quotes:

Hackers need to understand the theory of computation about as much as painters need to understand paint chemistry.

Hackers start original and get good, and scientists start good, and get original.

Everyone by now knows the danger of premature optimization. I think we should be just as worried about premature design.

When you switch to a new model, you realize how much software development is affected by the way it is released.

Paying attention is more important to reliability than moving slowly.

Steve Jobs once said that the success or failure of a stratup depends on the first ten employees. I agree.

Object oriented programming offers a sustainable way to write spaghetti code.

C# Gotcha

I've just spent 10 minutes blankly staring at my screen trying to figure out why the heck an ultra simple piece of C# didn't work... Suppose you create the following and compile it into an assembly called JSL.HelloWorld.dll

namespace JSL.HelloWorld
{
    public class Example
    {
        //...
    }
}

And then you write a test for it...

namespace Tests.JSL.HelloWorld
{
    using JSL.HelloWorld;
    using NUnit.Framework;

    [TestFixture]
    public class ExampleTest
    {
        [Test]
        public void Eg()
        {
            Example puzzle = new Example();
            //...
        }
    }
}

Looks fine. Yet when you compile the test csc complains that "the type or namespace name 'Example' could not be found...". Ten minutes blank staring follows. The problem is there are two namespaces called JSL.HelloWorld. There's one that's global that contains the class called Example we're after. And there's another one inside the namespace called Tests (called Tests.JSL.HelloWorld). So the compiler tries to resolve Example in Tests.JSL.HelloWorld but not in JSL.HelloWorld. One solution is as follows:

namespace Tests.JSL.HelloWorld
{
    using global::JSL.HelloWorld;
    using NUnit.Framework;

    [TestFixture]
    public class ExampleTest
    {
        //...
    }
}

BCS SPA 5th Jan 2005

Immo Hüneke has mercilessly bullied me into speaking at a BCS SPA meeting in central London. It'll be essentially the same talk I gave to the North East branch - a hotch potch of interesting quotes and various related topics loosely knitted together into something vaguely resembling a presentation.

The End of Certainty

...is the title of a book by Ilya Prigogine. It's subtitled Time, Chaos, and the New Laws of Nature and I reckon at least two of those three apply to software. Prigogine is a Nobel Prize winner (in Chemistry) and has worked on problems of non-equilibrium, complexity, self-organization, entropy, etc, for over four decades. Rather than writing an extensive review I'm going to open the book at a few random pages...

A nonequilibrium system may evolve spontaneously to a state of increased complexity.

Bifurcations are a source of symmetry breaking...Bifurcations are the manifestation of an intrinsic differentiation between parts of the system and its environment.

Once we have dissipative structures we can speak on self-oganization.

...order can only be maintained by self-organization.

...constraints do not eliminate creativity, they provoke it.

...our position is that classical mechanics is incomplete because it does not include irreversible processes associated with an increase in entropy.

There is a necessary trade off between certainty at a given time for continuity through time.

Recommended.

I've won something!

I'm chuffed to learn one of my articles has won best Overload article for the year (the year in question being 2003). Writing unpaid articles isn't as altruistic as it appears. You learn a great deal by writing. If you're a developer your job is writing descriptions. Writing matters. Richard Gabriel's advice to developers is to learn poetry. And Dijkstra said that the best indicator of a developers skill was mastery of their native tongue. One of Michael Jackson's lexicon entries is called simply 'Descriptions'.

ACCU 2005 Conference

I'll be speaking at the ACCU conference held 20th to 23rd April 2005 (with an additional pre-conference tutorial day on the 19th). These are always great developer focused conferences. Confirmed speakers include Bjarne Stroustrup, Jim Coplien, and Kevlin Henney. More details.