Mark Needham

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.

I was browsing through our tests today and noticed a test along these lines (simplified for example purposes):

[Test, ExpectedException(typeof(Exception))]
public void ShouldThrowExceptionIfNoBarSet()
{
    var bar = new Foo(null).Bar;
}

public class Foo
{
	private readonly string bar;
 
	public Foo(string bar)
	{
    		this.bar = bar;
	}
 
	public string Bar
	{
    		get
    		{
        		if (bar == null)
        		{
            		throw new Exception("No bar");
        		}
        		return bar;
    		}
	}
}

What I found strange here is that ‘bar’ is never used and Resharper points out as much. If we try to remove it, however, the code no longer compiles.

[Test, ExpectedException(typeof(Exception))]
public void ShouldThrowExceptionIfNoBarSet()
{
    new Foo(null).Bar;
}

Only call, assignment, increment, decrement, and new object expressions can be used as a statement.

We therefore need to assign the call to Bar to a variable even though we never intend to reference it.

This problem wouldn’t happen if Bar was a method instead.

[Test, ExpectedException(typeof(Exception))]
public void ShouldThrowExceptionIfNoBarSet()
{
    new Foo(null).Bar();
}

public string Bar()
{
    if (bar == null)
    {
        throw new Exception("No bar");
    }
    return bar;
}

Which got me thinking how do we know when to use a method and when to use a property?

Clearly if there are parameters to be passed in then we have no choice but to use a method since we can’t call properties with parameters.

If we are simply returning data values then we might as well just use properties since this is what they were made for. We can even make use of automated properties to smooth the process.

Which leaves the situation where there is some logic that needs to be calculated, no outside data is needed to do this calculation and a result is returned to the client.

Probably because of the Java influence my preference would be to do this using a method but I don’t really have any other justification for not using a property to achieve the same thing.

Discussing this briefly with Dave we thought maybe if a property is used then the execution needs to be idempotent (i.e. return the same result every time) although the argument could be made that well written methods should also be side effect free. Eric Evans’ advocates writing side effect free functions in Domain Driven Design for example.

Does anyone have any compelling reasons why or why not to use one or the other?

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?

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);

I had thought that with the ability to use the new object initalizer syntax in C# 3.0 meant that the builder pattern was now no longer necessary but some recent refactoring efforts have made me believe otherwise.

My original thought was that the builder pattern was really useful for providing a nicely chained way of creating objects, but after a bit of discussion with some colleagues I have come across three different reasons why we might want to use the builder pattern to create test data:

• It creates a nice to read fluent interface describing the object being created. This argument holds more for Java rather than C# where we now have object initializers.
• Domain objects are a bit complicated to create – encapsulate this logic in the builder.
• We want to default non null data on some of the fields in our object. If we don’t explicitly set a value for a property in C# it defaults to null.

Even with the object initializer syntax we can still end up having to specify extra data that we don’t really care about in our test. The following is not uncommon:

new Foo {Bar = "bar", Baz = "baz", Bling = "bling"};

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

Let’s say we only care about Bar for this test though but Baz and Bling are both being used in our code so we end up with a Null Reference Exception if we don’t set values for them. We can quickly end up having this redundant data being repeated across all our tests.

In steps the builder pattern!

new FooBuilder().Bar("bar").Build();

public class FooBuilder
{
    private string bar = "defaultBar";
    private string baz = "defaultBaz";
    private string bling = "defaultBling";
 
    public FooBuilder Bar(string value)
    {
        bar = value;
        return this;
    }
 
    public FooBuilder Baz(string value)
    {
        baz = value;
        return this;
    }
 
    public FooBuilder Bling(string value)
    {
        bling = value;
        return this;
    }
 
    public Foo Build()
    {
        return new Foo {Bar = bar, Baz = baz, Bling = bling};
    }
}

It takes a bit more code to setup but every time we use the builder it saves us typing in extra data that we don’t need.

It would be even better if we could not have to call that ‘Build’ method and we can get around this by using the implicit operator, the problem being that you need to apply it to the target class (i.e. Foo) rather than the class you want to implicitly convert from (i.e. FooBuilder).

I don’t really want to change a production code class just for test purposes so the ‘Build’ will have to stay in there for the time being.

In my continued reading of F# one of the ideas I’ve come across recently is that of partial function application.

This is a way of allowing us to combine different functions together and allows some quite powerful syntax to be written.

The term ‘currying’ is perhaps a better known term for describing this although as I understand they are not exactly the same.

Currying is where we return a function that has been partially applied, in such a way that we can chain together a group of functions with a single argument.

I first came across this idea with the forward piping operator when reading about Matthew Podwysocki’s FsTest project but there is an even cleaner way of chaining functions together using Function Composition.

The function composition operator (>>) is defined thus:

> (>>);;
val it : (('a -> 'b) -> ('b -> 'c) -> 'a -> 'c)

We take in two functions (‘a -> ‘b and ‘b -> ‘c) and one value (‘a).
We evaluate the first function (‘a -> ‘b) with the argument ‘a and then pass the result to the second function (‘b -> ‘c).

The way I understand this:

• The first function takes in ‘a (which is the 3rd argument passed to >>) and returns ‘b
• The second function takes in ‘b (which is the return value of the first function) and returns ‘c (which is the return value of >>)

Chris Smith perhaps best explains this as follows:

> let inline (>>) f g x = g(f x)
val inline ( >> ) : ('a -> 'b) -> ('b -> 'c) -> 'a -> 'c

Given two functions (f, g) and a value x compute the result of f(x) and pass the result to g.

From my reading so far this operator makes it even easier to write code in a declarative way (although I suppose the functional programming approach does encourage that in the first place).

We can achieve a lot of this nice declarative style by using the forward piping operator (|>) but the function composition operator takes it one step further:

Say we want to take a list of numbers, square all of them and then only show the negative ones:

let findOddSquares = List.map (fun x-> x*x) >> List.filter (fun x -> x%2 <> 0);;

If we did this using the forward piping operator it would read like this i.e. we need to explicitly define the list:

let findOddSquares list = list |> List.map (fun x-> x*x) |> List.filter (fun x -> x%2 <> 0);;

It’s not that much more verbose but there’s less code for doing the same thing if we use the function composition operator. I still think the forward piping operator works nicely when we just want to switch the order of the function and the data though:

> [1..10] |> findOddSquares
val it : int list = [1; 9; 25; 49; 81]

As with all my F# posts, I’m still learning so please point out if I have anything wrong. Chris Smith has a closer to real life example of how to use partial function application that probably shows the benefits more than I have here.

* Update *

As pointed out in the comments I’m actually finding the odd squares not the negative ones as I originally posted.

Continuing on my F# journey I came across a post by Ben Hall describing the approach he takes when learning a new programming language.

One of the approaches he describes is that of writing unit tests to help keep your learning on track. I’ve only been using the F# interactive console so far so I thought I’d give it a try.

After reading about the somewhat convoluted approach required to use NUnit or MBUnit to write F# unit tests I came across XUnit.NET via Matthew Podwysocki’s blog post about FsTest – a testing DSL he’s written to use on top of XUnit.NET.

One of the cool F# features I came across while reading Matthew’s post is the Forward Operator (|>).

This is particularly useful for writing test assertions which read like English. For example:

[<Fact>] let list_should_contain_3() = [1..5] |> should contain 3

Typically we would have the function followed by the data we want to apply it against but using this operator allows us to do it the other way around.

From my understanding the forward operator (also known as the push operator) pushes the value from the left hand side of the function to the first parameter of the function.

To use a simpler example of adding 5 to a number.

Normally we would do this:

> (fun x -> x+5) 5;;
val it : int = 10

Using the forward operator we can do this instead:

> 5 |> (fun x -> x+5)
val it : int = 10

If we look at the definition of “|>” this makes a bit more sense:

> (|>);;
val it : ('a -> ('a -> 'b) -> 'b) = <fun:clo@84>

It takes in 2 arguments “‘a” and “(‘a -> ‘b)” and returns “‘b”.

The first argument in this case is the value ’5′ and the second is a function which takes in an “‘a” and returns a “‘b”, in this case the (x -> x +5) function.

Armed with that knowledge the DSL example hopefully now makes more sense. To recall with the full code:

#light
open Xunit
 
let should f actual = f actual
let contain (expected: int) (actual: int list) = Assert.Contains(expected, actual)
 
[<Fact>] let list_should_contain_3() = [1..5] |> should contain 3

This is the same as writing the following:

[<Fact>] let list_should_contain_3() = should contain 3 [1..5]

Working from the ‘should’ outwards…

> should;;
val it : (('a -> 'b) -> 'a -> 'b) = <fun:clo@0_1>

It expects to take in a function (‘a -> ‘b), a value (‘a) and will return a value (‘b).

In this case that function is ‘contain’:

> contain;;
val it : (int -> int list -> unit) = <fun:clo@0_2>

It expects to take in two values (an int and a list of ints) and doesn’t return any value (unit is the equivalent of void in C#.)

Evaluating both together:

> should contain;;
val it : (int -> int list -> unit) = <fun:clo@88_1>

Here we have a partial application of the ‘should’ function i.e. we have only passed in one of the arguments (the ‘contain’ function). We have now created another function which requires an int and a list of ints and returns nothing.

If we now take the whole statement together:

[1..5] |> should contain 1;;

It seems like the [1..5] should be applied as the first argument to the ‘contain’ function but in actual fact the precedence rules dictate that the right hand side of the “|>” gets evaluated first meaning that the 1 is passed as the first argument to ‘contain’.

The [1..5] is passed in as the second argument to the ‘contain’ function completing all the inputs needed by the expression and therefore executing the Assert.Contains(…) assertion.

Matthew Cochran has an article which helps explain the operator with some diagrams and Matthew Podwysocki talks about it more in his post about language oriented programming.

I’m new to F# so if I’ve got anything wrong about the way this works please let me know.

I’ve been spending a bit of time working through the Real World Functional Programming book to learn a bit about F# and one of the cool features I came across today (while reading Chris Smith’s post on F# lists) is the Option type.

I first came across this idea a few months ago when discussing null handling strategies with a colleague who pointed out that you could get around this problem in Scala by using the Option class.

From what I can tell this works pretty much the same way and solves the problem that we have when we want to perform an operation but don’t know whether or not a value will be returned.

If a value is returned then we don’t have a problem, but if not then we want a clean way of handling this.

One example of this is when trying to retrieve a value from a collection. When we try to get a value which doesn’t exist this would typically throw an exception.

To give an F# example, trying to find the value 7 in a list from 1-5:

1

List.find (fun x -> x = 7) [1..5];;

This throws the following exception:

1
2
3

System.Collections.Generic.KeyNotFoundException: The item was not found in the collection
   at Microsoft.FSharp.Core.Operators.not_found[T]()
   at <StartupCode$FSI_0277>.$FSI_0277._main()

Luckily there is another way of trying to find this value:

1

List.tryfind (fun x -> x = 7) [1..5];;

val it : int option = None

Note that the type is now ‘int option’ with a value of ‘None’. If we search for a value that does exist:

1

List.tryfind (fun x -> x = 3) [1..5];;

val it : int option = Some 3

We get a return value of ‘Some 3′.

The beauty of this approach comes when pattern matching against these values. To give a contrived example:

1
2
3
4
5

let find value list =
    let option = List.tryfind(fun item -> item = value) list
    match option with
    | None -> printfn "Value %d not found" value
    | Some(valueFound) -> printfn "Found value: %d" valueFound;;

> find 1 [1..5];;
Found value: 1
val it : unit = ()

> find 6 [1..5];;
Value 6 not found
val it : unit = ()

I really like this idea and it seems cleaner than approaches I have used in C# and Java to achieve a similar outcome. I’m sure I’ll come across more usages for it as my knowledge of F# increases.

Incidentally, Luis Diego Fallas has written a cool post showing how to use option types in C#. The syntax obviously isn’t quite as clean as it is in F# but it still reads reasonably nicely.

I had an interesting discussion with a colleague last week about the names that we give to variables inside lambda expressions which got me thinking about the context that we should need to hold when reading code like this.

The particular discussion was around an example like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public class Foo
{
    private String bar;
    private String baz;
 
    public Foo(String bar, String baz)
    {
        this.bar = bar;
        this.baz = baz;
    }
 
    public override string ToString()
    {
        return string.Format("{0} - {1}", bar, baz);
    }
 
}

1
2
3
4

var oneFoo = new Foo("bar", "baz");
var anotherFoo = new Foo("otherBar", "otherBaz");
 
new List<Foo> {oneFoo, anotherFoo}.Select(foo => foo.ToString().ToUpper()).ForEach(Console.WriteLine);

I suggested that we could just replace the ‘foo’ with ‘x’ since it was obvious that the context we were talking about was applying a function on every item in the collection.

My colleague correctly pointed out that by naming the variable ‘x’ anyone reading the code would need to read more code to understand that x was actually referring to every ‘Foo’ in the collection. In addition naming the variable ‘x’ is quite lazy and is maybe equally bad as naming normal variables x,y and z (unless they’re loop indexes) since it is completely non descriptive.

The only real argument I can think of for having it as ‘x’ is that it makes the code a bit more concise and for this particular example I had to change the name of my first Foo to be ‘oneFoo’ so that I could use the variable name ‘foo’ inside the block since other variables in the same method are accessible from the closure.

I’m not sure what the good practice is in this area. I’ve done a little bit of work with Ruby closures/blocks and the convention there seemed to be that using single letter variables for blocks was fine.

In this case the extra context wouldn’t be that great anyway but I think trying to keep the necessary context that someone needs to remember as small as possible seems to be a reasonable rule to follow.

One of the things I really disliked when I first came across C# 3.0 code was lambda functions.

At the time I remember speaking to my Tech Lead and expressing the opinion that they were making the code harder to understand and were valuing conciseness over readability.

After a week of reading about the new C# features and understanding how they worked the code was now more readable to me and a lot of the boiler plate code that I had come to expect was no longer necessary.

My favourite example of the power of lambda is when we want to iterate through a collection of items and apply the same operation to every item in the collection.

In normal C# we might do this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public class Foo
{
    private String bar;
    private String baz;
 
    public Foo(String bar, String baz)
    {
        this.bar = bar;
        this.baz = baz;
    }
 
    public override string ToString()
    {
        return string.Format("{0} - {1}", bar, baz);
    }
 
}

1
2
3
4
5
6
7
8
9

var foos = new List<Foo>();
foos.Add(new Foo("bar1", "baz1"));
foos.Add(new Foo("bar2", "baz2"));
 
var fooString = new List<String>();
foreach (var foo in foos)
{
    fooString.Add(foo.ToString());
}

Using the power of C# 3.0 we can change that last for each statement to read something like this:

1

var fooString = foos.Select(f => f.ToString());

This is much more concise but I think the judgement on its readability depends on one’s understanding of the language feature.

One idea I am considering trying is using methods which describe more clearly what the lambda function is doing. This is an idea I came across from Kris Kemper’s post about using similar Ruby language features.

In the example I gave perhaps wrapping the foo.Select(…) in a method called ‘ConvertToStringRepresentation()’ might make it more readable – it’s clearly up for debate though.

When I was learning how lambda worked I found it useful to be able to do the comparison of how you would write code without it and being able to compare that with how you could do it with lambda. I also found having some understanding of how Ruby blocks worked made it easier as well.

Clearly having powerful language features means that a language is much easier to abuse but I think if used sensibly then readability and conciseness need not be mutually exclusive.