Mark Needham

One refactoring I was doing last week was to try and remove the use of some getters/setters on one of our objects so that it was better encapsulated and all the behaviour related to it happened in one place.

The change involved introducing a constructor to initialise the object rather than doing so using the new object initialiser syntax and initalising it using the properties.

My initial approach was to find all the usages of these properties and then remove each usage one by one, running our suite of tests against the code after each change to ensure that nothing had broken as a result of the change.

While we were doing this my colleague pointed out that it would probably be quicker to just comment out the properties code and then recompile the code – the list of errors would then point out the areas which relied on the properties and we could then fix the code that way.

It’s a technique I’ve used previously and it worked out reasonably well because there were only 10 or so usages, meaning we were able to make all those changes and run the tests in under ten minutes.

I think if there had been bigger changes to make – for example if the properties had been being used to expose the data all over the application (luckily we only had one case of this) then the smaller steps approach may have been preferable.

Getting the balance between taking small steps and getting rapid feedback was also a consideration here.

We were running our unit and javascript tests as we made the changes since we were uncertain exactly what impact the changes would have. It took around 70 seconds to run these tests, which I think encouraged slightly bigger steps so that we weren’t sitting around waiting too often.

Both of these approaches are useful and it seems to me that maybe a combination of them, at different stages of our refactoring, would prove to be most useful.

One of the inevitabilities of most projects is that at some stage there is going to need be some sort of integration.

The likes of Alistair Cockburn in Crystal Clear and Andy Hunt/Dave Thomas in The Pragmatic Programmer talk of the need to do integration early rather than letting it wait until later, but why?

Get the pain out the way

To some degree every time we try to integrate there is going to be some level of pain – for me it therefore makes sense that we take this pain early on when we have the chance to do something about it rather than leaving it until later and being surprised at the problems it causes.

We never really know that the system actually works as expected until it is fully integrated, and integration inevitably leads to situations which we didn’t know existed previously.

The potential problem we need to be careful about here is that we still deliver features with business value while doing our early integration otherwise we end up with the problem that we seem to be delivering absolutely nothing.

Code can be more example driven

When we integrate later on one problem we face is that we have to try and assume what the integration will be like rather than actually knowing.

While it is possible to somewhat isolate ourselves from other systems, at some stage we need to integrate and this can typically lead to different data flowing through, in a different format than expected and we need to handle these differences.

If we integrate late we are putting ourselves into a guessing game of what we think we are going to integrate against and this leads us down the path of assumption driven development.

This inevitably leads to us coding for some situations which won’t actually happen when we are integrated and missing out some situations which we didn’t actually know could happen until we integrated.

Less inventory

In lean terms inventory is a product or part of a product which is basically in a state of waiting – either waiting for something to be done to it or waiting for a customer to buy it.

I think we can find a similar analogy in terms of story cards where a part of that story is to integrate with another system for example.

When we do the integration work needed later on the additional problem we face is that we naturally lose some knowledge in the time that the story is sitting waiting.

In addition there is also wasted time as people regain the context of how the integration fits into the overall functionality of the story.

An interesting new feature in C# 3.0 is that of automatic properties on objects – this allows us to define a get/set property and the creation of the underlying field is taken care off for us.

We can therefore create a class like this:

public class Foo {
	public string Bar { get; set; }
}

Now ignoring the fact that it’s terrible OO to write a class like that, one thing that we’ve been wondering is what’s the difference between doing the above and just creating a public field on Foo called Bar like so:

public class Foo 
{
	public string Bar;
}

In terms of how we use the class in our code it’s conceptually the same but there are a couple of subtle differences.

We can change our implementation more easily if we use the automated properties. If we decide that we want to do something else apart from just setting a field or returning it then we can do that more easily without having to recompile assemblies that depend on that class.

If we decided we only wanted the getter to be public but to have a private setter that would be an easier change using automated properties, and if we want to reflect on the class I find it’s much easier to do that when we have properties rather than fields.

That’s all I can think of at least. Are there any other differences?

We’ve been trying to include some properties into our build file from a properties file today but no matter what we tried the properties were not being set.

We eventually realised that the build file has an XML Namespace set on the project element.

<project name="..." xmlns="http://nant.sf.net/schemas/nant.xsd">

It turns out that if you want to include a properties file in your build file, like so:

<include buildfile="properties.xml" />

…you need to put the namespace on the project attribute of that file as well, otherwise its properties don’t get picked up.

Our properties file therefore needs to look like this, assuming that we have a namespace set on the build file.

<project name="properties" xmlns="http://nant.sf.net/schemas/nant.xsd">
	<property name="foo" value="bar" />
</project>

What’s a bit confusing is that on the NAnt documentation page for the include task it says that project element attributes are ignored! That’s not what we found!

I wrote about a month or so ago about the functional collection parameters now available in C# and certainly one of the most fun refactorings for me is trying to get code written using a for loop into a state where it is using one of these.

With a bit of help from my colleague James Crisp, these are some of the most common refactorings that I have come across so far.

There’s a little bit of repetition with regards to my previous post but I think it’s interesting to see the procedural approach to solving this problems versus the functional approach.

For the sake of the examples, the following classes are common:

public class Foo
{
    private String bar;
    private String baz;
    private readonly bool specialFlag;
 
    public Foo(string bar, string baz, bool specialFlag)
    {
        this.bar = bar;
        this.baz = baz;
        this.specialFlag = specialFlag;
    }
 
    public bool HasSpecialFlag()
    {
        return specialFlag;
    }
}
 
public class NewFoo
{
    public NewFoo(Foo foo)
    {       
    }
}
 
public class NumericFoo
{
    public int Value { get; set; }
}

Going from one collection to another conditionally

var foos = new List<Foo> {new Foo("bar1", "baz2", true), new Foo("bar2", "baz2", false)}.Where(foo => foo.HasSpecialFlag());
 
var newFoos = new List<NewFoo>();
foreach (var foo in foos)
{
    newFoos.Add(new NewFoo(foo));
}

We started off well using the ‘Where’ method to reduce the original list but we can do even better!

var foos = new List<Foo> {new Foo("bar1", "baz2", true), new Foo("bar2", "baz2", false)};
foos.Where(foo => foo.HasSpecialFlag())
    .Select(foo => new NewFoo(foo));

Not significantly less code but it removes the need for more state in our code and makes the code more expressive at the same time which can only be a good thing.

Returning just one result

I came across some code last week which was iterating through a collection and then returning the first item which matched a certain criteria.

This would be useful if we wanted to get the first Foo object which has the special flag set for example.

private Foo GetSpecialFoo(List<Foo> foos)
{
    foreach (var foo in foos)
    {
        if(foo.HasSpecialFlag())
        {
            return foo;
        }
    }
    return null;
}

My initial thoughts on coming upon this code were that it should be possible to get rid of the loop but I wasn’t sure how to do the return. Luckily the ‘First’ method solves this problem.

private Foo GetSpecialFoo(List<Foo> foos)
{
    return foos.Where(foo => foo.HasSpecialFlag()).First();
}

Accumulating some values

Adding values in collections together is surely one of the most common operations we do and functional collection parameters can help us here too.

var numericFoos = new List<NumericFoo> {new NumericFoo {Value = 2}, new NumericFoo {Value = 5}};
int total = 0;
foreach (var numericFoo in numericFoos)
{
    total += numericFoo.Value;
}

Introducing a functional approach here gives us the following code:

var numericFoos = new List<NumericFoo> {new NumericFoo {Value = 2}, new NumericFoo {Value = 5}};
int total = numericFoos.Sum(foo => foo.Value);