Mark Needham

I was recently discussing F# with a couple of colleagues and one thing that came up is the slightly different ways that we might choose to interact with certain .NET framework classes compared to how we use those same classes in C# code.

One of those where I see potential for different use is the Dictionary class.

In C# code when we’re querying a dictionary to check that a value exists before we try to extract it we might typically do this:

public string GetValueBy(string key) 
{
	var dictionary = new Dictionary<string, string>() { {"key", "value" } };
 
	if(dictionary.ContainsKey(key)) 
	{
		return dictionary[key];
	}	 
	return ""; // maybe we'd do something else here but for the sake of this we return the empty string
}

There is an alternative way to do this but it makes use of the ‘out’ keyword so it’s generally frowned upon.

public string GetValueBy(string key)
{
	var dictionary = new Dictionary<string, string>() {{"key", "value"}};
	string value = "";
	dictionary.TryGetValue(key, out value);
	return value;
}

In F# when we make use of a method which effectively defines a second return parameter by using the ‘out’ keyword the return value of that method becomes a tuple containing that value.

For example when querying Dictionary:

open System.Collections.Generic
open System
open System.Globalization
 
let testDictionary = 
    let builder = new Dictionary<string, string>()
    builder.Add("key1", "value")
    builder
 
let getByKey key =
    let result, value =  testDictionary.TryGetValue(key)
    if(result) then value result else ""

The return type of TryGetValue is ‘bool * string’ in this case and by assigning that result to two different values we can get the appropriate values. This is certainly a time when tuples are really useful for simplifying our code.

We could have made use of an ‘out’ parameter as we did in C# but I think it’s much easier to just use the tuple. Dustin Campbell describes the other ways we could extract a value from a dictionary on his blog.

It’s not significantly more concise code wise compared to the C# way of doing things although from a brief look at the way that the Dictionary code works in Reflector theoretically we are making less calls to the underlying data structure to get the value from it.

I tried timing 100,000 accesses to a dictionary with each approach to see if the total time would be significantly different but there wasn’t any noticeable difference.

There are other ‘Try…’ methods defined in the base class library – DateTime for example has some more – which I’ve never used in C# so I’d be intrigued to see whether other languages that run on the CLR will make use of these methods.

The Book

Real World Functional Programming by Tomas Petricek with Jon Skeet (corresponding website)

The Review

I decided to read this book after being somewhat inspired to learn more about functional programming after talking with Phil about his experiences learning Clojure. I’m currently working on a .NET project so it seemed to make sense that F# was the language I picked to learn.

What did I learn?

• I’ve worked with C# 3.0 since around July 2008 so I had a bit of experience using some of the functional features in C# before picking up this book. I therefore found it very interesting to read about the history of lambda and the different functional languages and how they came into being. Having this as an opening chapter was a nice way to introduce the functional approach to programming.
• Immutable state is one of the key ideas in functional programming – this reminded me of a Joe Armstrong video I watched last year where he spoke of his reduced need to use a debugger when coding Erlang due to the fact that there was only one place where state could have been set rather than several as is the case with a more imperative approach. We have been trying to code with immutable state in mind in our coding dojos and while it takes a bit more thinking up front, the code is much easier to read when written that way.
• Separating the operations from the data is important for allowing us to write code that can be parallelised, focusing on what to do to the data rather than how to do it. Sadek Drobi has a nice illustration of what he calls mosquito programming vs functional programming on page 14 of the slides of his QCon presentation. It describes this idea quite nicely.
• A cool technique that Phil taught me when reading language related books is to have the PDF of the book on one side of the screen and the REPL (in this case F# interactive) on the other side so that you can try out the examples in real time. The book encourages this approach and all the examples follow on from previous ones which I think works quite well for gradually introducing concepts.
• Functions are types in functional programming – I have had a bit of exposure to this idea with Funcs in C# but partial function application is certainly a new concept to me. I can certainly see the value in this although it took me a while to get used to the idea. I am intrigued as to where we should use a functional approach and where an OO approach when working in C#. I think both have a place in well written code.
• F#’s implicit static typing is one of my favourite things about the language – you get safety at compile time but you don’t waste a lot of code writing in type information that the compiler should be able to work out for you. It has the strongest type inference of any language that I’ve worked with and I thought it was quite nice that it was able to work stuff out for me instead of me having to type it all out.
• I really like the idea of option types which I first learnt about from the book. Having the ability to explicitly define when a query hasn’t worked is far superior to having to do null checks in our code or the various strategies we use to get around this.
• I thought it was cool that in the early chapters the focus with the F# code is to provide examples that you can just get running straight away instead of having to worry about the need to structure your code in a maintainable way. After I had a reasonable grasp of this then the chapter about using record types to structure code in an OO way come up. I still prefer the C# style of structuring code in objects – it just feels more natural to me at the moment and manages the complexity more easily. It is quite easy to switch between the two styles using features like member augmentation so I think it’s probably possible to mix the two styles quite easily.
• We can use modules to make F# functions which don’t fit onto any class available from C# code. The code is not as clean as if we were writing just for it to be used by other F# code but it’s not too bad:

  module Tests =                                               
      let WithIncome (f:Func<_, _>) client =                  
          { client with Income = f.Invoke(client.Income) }

  We can then call this in our C# code like so:

  Tests.WithIncome(income => income + 5000, client);

  Dave Cameron has written more about this.

• Although I studied data structures at university I don’t really pay a great deal of attention to them in terms of performance normally so it was interesting to see the massive performance hit that you take when appending a value to the end of an F# list compared to adding it to the beginning. F# uses linked lists so if we want to add something to the end then there is a lot of recursion involved to do that which is quite costly. In terms of big O notation we go from O(N) where N is the number of elements to append to O(N*M) in terms of performance.
• Chapter 13 is about parallel processing of data for which I found I needed to download the Microsoft Parallel Extensions to .NET Framework 3.5, June 2008 Community Technology Preview and then add a reference to ‘C:\Program Files\Microsoft Parallel Extensions Jun08 CTP\System.Threading.dll’ in order to make use of those features.
• The author provides a nice introduction to continuations and how you can make use of them in F# by using continuation passing style. I’m intrigued as to how we can make use of these in our code – we do a bit already by making use of callbacks which get fired at a later point in our code – but from what I’ve read it sounds like we should be able to do even more especially when writing web applications.
• Asynchronous workflows are also made very accessible in this book – I had previously struggled a bit with them but the author covers the various API methods available to you and then explains what is going on behind the syntactic sugar that F# provides. I have made some use of these in the little twitter appication that I’ve been working on now and again.

In Summary

I really enjoyed reading this book – it’s my first real foray into the world of functional programming since university and I think I understand the functional approach to programming much better than I did back then from reading this book.

It takes an approach of introducing various functional programming concepts before showing examples of where that concept might come in useful when coding. It’s also particularly useful that examples are shown in C# and F# as this made it much easier for me to understand what the F# code was doing by comparing it with the code in a more familiar language.

I’d certainly recommend this to any .NET developers curious about learning how to apply ideas derived from functional programming to their C# code and indeed to any developers looking to start out learning about functional programming.

A colleague and I were looking through some code that I worked on a couple of months ago where I had created a one level hierarchy using inheritance to represent the response status that we get back from a service call.

The code was along these lines:

public class ResponseStatus
{
    public static readonly ResponseStatus TransactionSuccessful = new TransactionSuccessful();
    public static readonly ResponseStatus UnrecoverableError = new UnrecoverableError();
 
    public virtual bool RedirectToErrorPage
    {
        get { return true; }
    }
}
 
public class UnrecoverableError : ResponseStatus
{
 
}
 
public class TransactionSuccessful : ResponseStatus
{
    public override bool RedirectToErrorPage
    {
        get { return false; }
    }
}

Looking at it now it does seem a bit over-engineered, but the main confusion with this code is that when you click through to the definition of ‘RedirectToError’ it goes to the ResponseStatus version of that property and it’s not obvious that it is being overridden in a sub class, this being possible due to my use of the virtual key word.

You therefore need to look in two places to work out what’s going on which isn’t so good.

A solution which we came up with which is a bit cleaner is like so:

public abstract class ResponseStatus
{
    public static readonly ResponseStatus TransactionSuccessful = new TransactionSuccessful();
    public static readonly ResponseStatus UnrecoverableError = new UnrecoverableError();
 
    public abstract bool RedirectToErrorPage { get; }
}
 
public class UnrecoverableError : ResponseStatus
{
    public override bool RedirectToErrorPage
    {
        get { return true; }
    }
}
 
public class TransactionSuccessful : ResponseStatus
{
    public override bool RedirectToErrorPage
    {
        get { return false; }
    }
}

When you have more response statuses then I suppose there does become a bit more duplication but it’s traded off against the improved ease of use/reading that we get.

It’s generally considered good practice to favour composition over inheritance and from what I can tell the virtual keyword is only ever going to be useful if you’re creating an inheritance hierarchy.

An interesting lesson learned.

While reading Real World Functional Programming I came across an interesting pattern that I have noticed in some code bases recently which I liked but didn’t know had been given a name!

The hole in the middle pattern, coined by Brian Hurt, shows a cool way of using higher order functions in order to reuse code in cases where the code typically looks something like this:

public void SomeServiceCall() 
{
	var serviceClient = CreateServiceClient();
 
	try 
	{
		serviceClient.MakeMethodCall();
	}
	catch(SomeServiceException someServiceException) 
	{
		// Handle exception
	}
	finally 
	{
		serviceClient.Close();
	}
}

The first and the third lines (initialisation and finalisation) are always the same but the service.MakeMethodCall() varies depending on which service we are using. The more services we have the more boring it gets writing out the same code over and over again.

In C# 3.0 we could reuse code in this situation by passing in a lambda expression which calls that method, allowing us to vary the important part of the method call while keeping the scaffolding the same.

public void SomeServiceCall(Action<TServiceClient> callService) 
{
	var serviceClient = CreateServiceClient();
 
	try 
	{
		callService(serviceClient);
	}
	catch(SomeServiceException someServiceException) 
	{
		// Handle exception
	}
	finally 
	{
		serviceClient.Close();
	}
}

SomeServiceCall(service => service.SomeMethodCall())

One of the things I’ve noticed with the ability to pass in functions to methods is that sometimes we end up making the code really difficult to read by doing so but when we’re dealing with services this seems to be one of the best and most obvious uses of Actions/Funcs in C# 3.0 and it leads to a more reusable and easy to understand API.

I recently started playing around with Scott Bellware’s Spec-Unit and Aaron’s Jensen’s MSpec, two frameworks which both provide a way of writing Context/Spec style tests/specifications.

What I particularly like about this approach to writing tests is that we can divide assertions into specific blocks and have them all evaluated even if an earlier one fails.

NUnit is our testing tool of choice at the moment and we wanted to try and find a way to test the mapping between the domain and service layers of the application.

Testing in the normal way was resulting in a test that was absolutely massive and a bit of a nightmare to debug when something changed.

Luckily Dave came up with the idea of using the TestFixtureSetUp attribute on a method which would setup the test data and then call the appropriate method on the object under test.

We could then have smaller tests which asserted various parts of the mapping.

[TestFixture]
public class FooAdaptorTest 
{
	private Foo foo;
	private FooMessage fooMessage;
 
	[TestFixtureSetUp]
	public void GivenWeTransformAFoo()
	{
		foo = new Foo { Bar = "bar", Baz = "baz" };
		fooMessage = new FooAdaptor().MapFrom(foo);	
	}
 
	[Test]
	public void ShouldMapBar() 
	{
		Assert.AreEqual(foo.Bar, fooMessage.Bar);	
	}
 
	[Test]
	public void ShouldMapBaz() 
	{
		Assert.AreEqual(foo.Baz, fooMessage.Baz);		
	}
}

Of course this is a very simple example, and in a real example we would test more than just one property per test.

The Setup method does get pretty big depending on how much mapping needs to be done but it seems a reasonable trade off for the increased readability we get in the smaller size of each of the tests.

I know this isn’t the normal way of using NUnit but I think it’s cool to try and think outside the normal approach to find something that works better for us.

I think it was Darren Hobbs who first introduced me to the idea of wrapping dates in our system to describe what that date actually means in our context, and after suffering the pain of passing some unwrapped dates around our code I think I can safely say that wrapping them is the way to go.

The culprit was a date of birth which was sometimes being created from user input and sometimes being retrieved from another system.

The initial (incorrect) assumption was that we would be passing around the date in the same string format and there was no point wrapping the value as we were never doing anything with the data.

It proved to be a bit of a nightmare trying to work out which state the data of birth was in various parts of the application and we ended up doing conversions to the wrong format and then undoing those and losing the formatting in other places!

Step 1 here was clearly not to pass around the date as a string but instead to convert it to a DateTime as soon as possible.

This is much more expressive but we can take this one step further by wrapping that date time in a DateOfBirth class.

public class DateOfBirth 
{
	private DateTime? dateOfBirth
 
	public DateOfBirth(DateTime? dateOfBirth) 
	{
		this.dateOfBirth = dateofBirth;
	}
 
	public string ToDisplayFormat()
	{
		return dateOfBirth == null ? "" : dateOfBirth.Value.ToString("dd MMM yyyy");
	}
}

When we want to display this object on the page we just have to call the ToDisplayFormat() and if that date format needs to change then we have only one place to make that change. Creating this class removed at least 3 or 4 ‘DateTime.Parse(…)’ and ‘DateTime.ToString(…)’ calls throughout the code.

Now we could achieve the same functionality using an extension method on DateTime? but it’s not as expressive as this in my opinion. It is also really obvious when looking at the code to know what type we are dealing with and it is really obvious when reading this class which method we will use to get the format to display to the user.

I will certainly be looking to wrap any DateTimes I come across in future.

Another interesting thing I’ve noticed in C# world is that there seems to be a trend towards using extension methods as much as possible. One area where this is particularly prevalent is when working with collections.

From reading Object Calisthenics and working with Nick I have got used to wrapping collections and defining methods on the wrapped class for interacting with the underlying collection.

For example, given that we have a collection of Foos that we need to use in our system we might wrap that in an object Foos.

public class Foos
{
    private readonly IEnumerable<Foo> foos;
 
    public Foos(IEnumerable<Foo> foos)
    {
        this.foos = foos;
    }
 
    public Foo FindBy(string id)
    {
        return foos.Where(foo => foo.Id == id).First();
    }
 
    // some other methods to apply on the collection
}

Extension methods provide another way of achieving the same thing while not needing to wrap it.

public static class FooExtensions
{
    public static Foo FindBy(this IEnumerable<Foo> foos, string id)
    {
        return foos.Where(foo => foo.Id == id).First();
    }
}

It seems like there isn’t much difference in wrapping the collection compared to just using an extension method to achieve the same outcome.

The benefit I see in wrapping is that we take away the ability to do anything to the collection that we don’t want to happen. You only have the public API of the wrapper to interact with.

The benefit of the extension method approach is that we don’t need to create the object Foos – we can just call a method on the collection.

I’m not sure which is a better approach – certainly languages which provide the ability to open classes seem to favour taking that approach over wrapping but I still think it’s nice to have the wrapper as it means you don’t have to be explicitly passing collections all around the code.

But maybe that’s just me.

Since it was pointed out in the comments on an earlier post I wrote about using the builder pattern how useful the implicit operator could be in this context we’ve been using it wherever it makes sense.

The main benefit that using this approach provides is that our test code becomes more expressive since we don’t need to explicitly call a method to complete the building of our object.

public class FooBuilder 
{
	private string bar = "defaultBar";
 
	public FooBuilder Bar(string value)
	{
		bar = value;
		return this;
	}
 
	public static implicit operator Foo(FooBuilder builder) 
	{
		return new Foo { Bar = builder.bar };
	}
}

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

We can then create a ‘Foo’ in our tests like this:

var foo = new FooBuilder().Bar("bar");

The type of ‘foo’ is actually ‘FooBuilder’ but it will be implicitly converted to Foo when needed.

Alternatively we can force it to Foo earlier by explicitly defining the type:

Foo foo = new FooBuilder().Bar("bar");

While playing around with the specification pattern to try and create a cleaner API for some querying of collections I tried to create a specification builder to chain together several specifications.

public interface IFooSpecification
{
    bool SatisfiedBy(Foo foo);
    IFooSpecification And(IFooSpecification fooSpecification);
}

public abstract class BaseFooSpecification : IFooSpecification
{
    public abstract bool SatisfiedBy(Foo foo);
    public  IFooSpecification And(IFooSpecification fooSpecification)
    {
        return new AndSpecification(this, fooSpecification);   
    }
}

public class FooBar : BaseFooSpecification
{
    private readonly string bar;
 
    public FooBar(string bar)
    {
        this.bar = bar;
    }
 
    public override bool SatisfiedBy(Foo foo)
    {
        return foo.Bar == bar;
    }
}

public class FooQuery 
{
    private FooBar fooBarSpecification;
    private FooBaz fooBazSpecification;
 
    public FooQuery Bar(string value)
    {
        fooBarSpecification = new FooBar(value);
        return this;
    }
 
    public FooQuery Baz(string value)
    {
        fooBazSpecification = new FooBaz(value);
        return this;
    }
 
 
    public static implicit operator IFooSpecification(FooQuery fooQuery)
    {
        // User-conversion to interface error message displayed by Resharper
 
    }
}

The intention was to be able to filter a collection of foos with code like the following:

foos.FindBy(new FooQuery().Bar("bar").Baz("baz"));

Unfortunately the C# language specification explicitly doesn’t allow this:

A class or struct is permitted to declare a conversion from a source type S to a target type T provided all of the following are true:

• …
• Neither S nor T is object or an interface-type.

User-defined conversions are not allowed to convert from or to interface-types. In particular, this restriction ensures that no user-defined transformations occur when converting to an interface-type, and that a conversion to an interface-type succeeds only if the object being converted actually implements the specified interface-type.

I tried casting to the BaseFooSpecification abstract class instead and although that does compile it seemed to be leading me down a path where I would need to change the ‘FindBy’ signature to take in a BaseFooSpecification which I wasn’t keen on.

It didn’t prove possible to implicitly convert to a BaseFooSpecification when the signature for the method expected an IFooSpecification even though BaseFooSpecification implements IFooSpecification.

I don’t think there is a way to get around this in C# 3.0 so I just ended up creating an explicit method to convert between the two – not quite as nice to read but the best I could come up with.

When I first heard about extension methods in C# it sounded like a pretty cool idea but I wasn’t sure how they differed to the idea of open classes that I had seen when doing a bit of Ruby.

After a bit of a struggle recently to try and override some extension methods on HtmlHelper in ASP.NET MVC it’s clear to me that we don’t quite have the same power that open classes would provide.

To start with we can’t access private variables of a class in an extension method – as far as I understand an extension method is just syntactic sugar to make our code look pretty at compile time.

We therefore only have access to public fields, methods and properties from extension methods. Anything protected is also out of our reach.

I’m no expert of Ruby’s open classes but from what I have read and remember you can override private methods, use private variables and even remove methods if you want to. We could also add methods to a specific instance of a class which we can’t do using extension methods.

We therefore tend to be limited to using C#’s extension methods for applying operations directly to an object – applying different types of formatting to strings is one common use.

Before extension methods existed this type of code would typically have gone on a StringUtils class so this is a definite improvement.

We can ‘add’ more functional methods to a class as long as it only uses data accessible from the class’ API but we haven’t tended to do this so much on the projects I’ve worked on.

The ability to override methods added to a class away from its original definition is something that we don’t have using extension methods.

As I mentioned we has some problems with this recently when trying to work out how to override some calls to HtmlHelper methods.

In this case it would have been nice to be able to open up the HtmlHelper class and change these methods. Unfortunately since they were defined as extension methods, extending HtmlHelper didn’t give access to them so we ended up coming up with a solution which feels a bit too hacky for my liking.

As Dare Obasanjo points out towards the end of his post we also don’t have the ability to create extension properties. Seeing as properties are compiled to get/set methods under the hood I wouldn’t have thought it would be that difficult to add this in the next release.

Overall though extension methods are a nice addition but they still don’t quite give us the full power that open classes would provide.

The object initializer syntax introduced in C# 3.0 makes it easier for us to initialise our objects in one statement but I think we need to remember that they are not named parameters and that there is still a place (a very good one actually) for creating objects from constructors or factory methods.

Unfortunately what I think the cleaner syntax does is encourage us to create objects with half the fields populated and half of them null by default.

When we didn’t have the object initializer syntax we would have to set properties on objects like so:

var foo = new Foo();
 
var bar = new Bar();
bar.Baz = new Baz();
 
foo.Bar = bar;

It takes a lot of extra boiler plate code to achieve this and it looks terrible, hopefully driving us towards using the constructor to initialise our objects.

Object initializers makes it much easier to achieve the same thing but at its worst we end up with code similar to the following which to me looks a bit like a horse shoe, an anti pattern in my opinion.

new Foo 
{ 
	Bar = new Bar 
	{ 
		Baz = new Baz 
		{
			Other = new Other
			{
				Value = "value",
				OtherValue = "otherValue"
			}
		}
	}
}

I don’t think we should write code like this – to me it’s not expressive and it’s difficult to understand why certain fields are set or not set. You end up having to think how this code fits into the bigger picture in order to understand it – extra context which shouldn’t be necessary.

From experience we also end up in the debugger much more frequently than should be the case, trying to work out why certain fields are set. I feel this leads to very implicit code where you have to work out what is going on/where you are in the work flow by checking the state of our objects.

Of course the problem here is the reliance on properties (i.e. getters/setters) to instantiate our objects rather than object initializer in itself but the new syntax has made it much easier for us to do it.

Certainly there are some times when it’s quite nice to have the object initializer syntax but as with most things we need to be careful not to overdo it.