Mark Needham

Thoughts on Software Development

Archive for the ‘functional-programming’ tag

Functional Thinking: Separating concerns

without comments

Over the weekend I was trying to port some of the neo4j import code for the ThoughtWorks graph I’ve been working on to make use of the REST Batch API and I came across an interesting example of imperative vs functional thinking.

I’m using the neography gem to populate the graph and to start with I was just creating a person node and then creating an index entry for it:

people_to_load = Set.new
people_to_load << { :name => "Mark Needham", :id => 1 }
people_to_load << { :name => "Jenn Smith", :id => 2 }
people_to_load << { :name => "Chris Ford", :id => 3 } 
 
command_index = 0
people_commands = people_to_load.inject([]) do |acc, person| 
  acc << [:create_node, {:id => person[:id], :name => person[:name]}]
  acc << [:add_node_to_index, "people", "name", person[:name], "{#{command_index}}"]
  command_index += 2
  acc
end
 
Neography::Rest.new.batch * people_commands

people_commands ends up containing the following arrays in the above example:

 [
  [:create_node, {:id=>"1", :name=>"Mark Needham"}], 
  [:add_node_to_index, "people", "name", "Mark Needham", "{0}"], 
  [:create_node, {:id=>"2", :name=>"Jenn Smith"}], 
  [:add_node_to_index, "people", "name", "Jenn Smith", "{2}"], 
  [:create_node, {:id=>"3", :name=>"Chris Ford"}, 
  [:add_node_to_index, "people", "name", "Chris Ford", "{4}"]
 ]

We can refer to previously executed batch commands by referencing their ‘job id’ which in this case is their 0 indexed position in the list of commands. e.g. the second command which indexes me refers to the node created in ‘job id’ ’0′ i.e the first command in this batch

In the neo4j REST API we’d be able to define an arbitrary id for a command and then reference that later on but it’s not implemented that way in neography.

I thought having the ‘command_index += 2′ was a bit rubbish because it’s nothing to do with the problem I’m trying to solve so I posted to twitter to see if there was a more functional way to do this.

My colleague Chris Ford came up with a neat approach which involved using ‘each_with_index’ to work out the index positions rather than having a counter. His final version looked like this:

insert_commands = people_to_load.map do |person|
  [:create_node, {:id => person[:id], :name => person[:name]}]
end
 
index_commands = people_to_load.each_with_index.map do |person, index|
  [:add_node_to_index, "people", "name", person[:name], "{#{index}}"]
end
 
people_commands = insert_commands + index_commands

The neat thing about this solution is that Chris has separated the two concerns – creating the node and indexing it.

When I was thinking about this problem imperatively they seemed to belong together but there’s actually no reason for that to be the case and we can write simpler code by separating them.

We do iterate through the set twice but since it’s not really that big it doesn’t make too much difference. to the performance.

Written by Mark Needham

June 12th, 2012 at 11:50 pm

Functional Programming: Handling the Options

with 7 comments

A couple of weeks ago Channing Walton tweeted the following:

Every time you call get on an Option a kitten dies.

As Channing points out in the comments he was referring to unguarded calls to ‘get’ which would lead to an exception if the Option was empty, therefore pretty much defeating the point of using an Option in the first place!

We’re using Dan Bodart’s totallylazy library on the application I’m currently working on and in fact were calling ‘get’ on an Option so I wanted to see if we could get rid of it.

The code in question is used to work out a price based on a base value and an increment value, both of which are optional.

I’ve re-created some tests to show roughly how it works:

@Test
public void myOptionsExample() {
    Assert.assertThat(calculate(Option.<Double>none(), Option.<Double>none(), 20), is(Option.<Double>none()));
    Assert.assertThat(calculate(Option.<Double>none(), Option.some(12.0), 20), is(Option.some(240.0)));
    Assert.assertThat(calculate(Option.some(50.0), Option.some(12.0), 20), is(Option.some(290.0)));
    Assert.assertThat(calculate(Option.some(50.0), Option.<Double>none(), 20), is(Option.some(50.0)));
}
private Option<Double> calculate(Option<Double> base, final Option<Double> increment, final int multiplier) {
    if(base.isEmpty() && increment.isEmpty()) {
        return Option.none();
    }
 
    if(increment.isEmpty()){
        return base;
    }
 
    double baseBit = base.getOrElse(0.0);
    double incrementBit = increment.get() * multiplier;
 
    return Option.some(baseBit + incrementBit);
}

We can get rid of the ‘increment.isEmpty()’ line by making use of a ‘getOrElse’ a few lines later like so:

private Option<Double> calculate(Option<Double> base, final Option<Double> increment, final int multiplier) {
    if(base.isEmpty() && increment.isEmpty()) {
        return Option.none();
    }
 
    double baseBit = base.getOrElse(0.0);
    double incrementBit = increment.getOrElse(0.0) * multiplier;
 
    return Option.some(baseBit + incrementBit);
}

In Scala we can often make use of a for expression when combining Options but I’m not sure it would help in this case because we want to return a ‘Some’ if either of the Options has a value and only return a ‘None’ if they’re both empty.

I can’t figure out how to get rid of that opening if statement – I tried pushing the options into a list and then calling ‘foldLeft’ on that to sum up the components but we still have the problem of how to deal with returning a ‘None’ when the list is empty.

If you know how to simplify that code either using totallylazy or another language please let me know in the comments!

Written by Mark Needham

March 21st, 2012 at 12:50 am

Posted in Java

Tagged with ,

Functional Programming: One function at a time

with one comment

As I mentioned in an earlier post I got a bit stuck working out all the diagonals in the 20×20 grid of Project Euler problem 11 and my colleague Uday ended up showing me how to do it.

I realised while watching him solve the problem that we’d been using quite different approaches to solving the problem and that his way worked way better than mine, at least in this context.

My approach was to try and drive out the solution from the top down which meant in this case:

  • Get all of the diagonals left to right by iterating over a 2 dimensional array and accumulating sub arrays of the values 1 row and 1 column greater than the current position.

I was stuck for ages trying to work out how to do that whereas Uday made it much easier by just focusing on one of the functions that we’d need, getting that to work and then moving onto the next one.

After we’d iterated with that approach a few times we had a bunch of functions that we could compose together to solve the initial problem.

We started with a simple function to find the value at position (x,y) in the array:

findValue :: Int -> Int -> [[Int]] -> Int
findValue x y grid = (grid !! x) !! y

We then worked on writing a function in the REPL which would find all the diagonals going down from the current position

[findValue (0+z) (0+z) grid | z <- [0..19]]

We eventually realised that running that from anywhere but the top left hand corner would throw an exception since we’d gone out of bounds of the array:

> [findValue (1+z) (1+z) grid | z <- [0..19]]
[49,31,23,51,3,67,20,97,45,3,24,44,52,26,32,40,4,5,48,*** Exception: Prelude.(!!): index too large

We then wrote a function to check that a given point was actually in the array:

hasItemSingle :: [a] -> Int -> Bool
hasItemSingle array position = position >= 0 && (length array - 1) >= position
 
hasItem :: [[a]] -> Int -> Int -> Bool
hasItem array x y = hasItemSingle array x && hasItemSingle (array !! x) y

And our function to calculate the diagonals then used that:

> [findValue (1+z) (1+z) grid | z <- [0..19], hasItem grid (1+z) (1+z) ]
[49,31,23,51,3,67,20,97,45,3,24,44,52,26,32,40,4,5,48]

That function eventually ended up like this:

diagonalAt :: Int -> Int -> [[Int]] -> [Int]
diagonalAt x y grid = [findValue (x+z) (y+z) grid | z <- [0..(length grid)], hasItem grid (x + z) (y + z)]

The nice thing about taking this approach of only thinking about one function at a time is that you can actually make some progress since you only need to think about a small part of the problem as compared to the whole thing.

I still start off trying to solve a problem from the outside in but if I get stuck then I start looking for some simple functions that I can write to get started and help me work towards an overall solution.

Written by Mark Needham

March 19th, 2012 at 11:25 pm

Posted in Haskell

Tagged with ,

Functional Programming: Shaping the data to fit a function

without comments

As I mentioned in my last post I’ve been working on Project Euler problem 11 and one thing I noticed was that I was shaping the data around a windowed function since it seemed to fit the problem quite well.

Problem 11 is defined like so:

In the 20×20 grid below, four numbers along a diagonal line have been marked in red.

Problem 11

The product of these numbers is 26 63 78 14 = 1788696.

What is the greatest product of four adjacent numbers in any direction (up, down, left, right, or diagonally) in the 20×20 grid?

I needed to get all the horizontals, verticals and diagonals into collections that I could then apply the function to and get the four adjacent numbers required by the problem.

That was reasonably easy for the horizontals and verticals:

leftToRight = concatMap (windowed 4) grid
topToBottom = concatMap (windowed 4) [[row !! (n-1) | row <- grid] | n <- [1..length grid]]
-- shortened for brevity
grid :: [[Int]]
grid = [[08,02,22,97,38,15,00,40,00,75,04,05,07,78,52,12,50,77,91,08],
       ....
        [01,70,54,71,83,51,54,69,16,92,33,48,61,43,52,01,89,19,67,48]]

In the first case we’re just running a map operation over each row and converting it into groups of 4 adjacent elements. By using concatMap we can ensure that the result is flattened back into a single collection.

To get the top to bottom values I had to first create a new array of arrays built up using values at the same column index in each row before applying the windowed function.

I found it much more difficult to get the diagonals into the right shape but luckily I bumped into Uday who helped me figure it out.

We started off by working out how to calculate all the numbers diagonally left to right from a specific point which resulted in this function:

diagonalAt :: Int -> Int -> [[Int]] -> [Int]
diagonalAt x y grid = [findValue (x+z) (y+z) grid | z <- [0..(length grid)], hasItem grid (x + z) (y + z)]

We had to add a hasItem function so that we didn’t try and call findValue on a position which didn’t exist on the grid:

hasItemSingle :: [a] -> Int -> Bool
hasItemSingle array position = position >= 0 && (length array - 1) >= position
 
hasItem :: [[a]] -> Int -> Int -> Bool
hasItem array x y = hasItemSingle array x && hasItemSingle (array !! x) y

findValue is just used to find the value at an (x,y) location:

findValue :: Int -> Int -> [[Int]] -> Int
findValue x y grid = (grid !! x) !! y

Now we had the ability to find out one diagonal we needed to find all the diagonals on the grid which we did like this:

diagonals :: [[Int]] -> [[Int]]
diagonals grid = filter (\x -> length x > 4) . map (\(x,y) -> diagonalAt x y grid) $ (diagonalPositions grid)
 
diagonalPositions :: [[Int]] -> [(Int, Int)]
diagonalPositions grid = [ (x,y) | x <- [0..(length grid)], y <- [0..length $ grid !! 0 ]]
 
diagonalValues = concatMap (windowed 4) (diagonals grid)

diagonalPositions creates a sequence of pairs which contain all the different positions in the grid where we want to try and find a diagonal from. We then map over that in diagonals and find the diagonal from each of those places.

We then had to do the same to find diagonals running from right to left:

diagonalUpwaysAt :: Int -> Int -> [[Int]] -> [Int]
diagonalUpwaysAt x y grid = [findValue (x+z) (y+(z * (-1))) grid | z <- [0,-1..(length grid * (-1))], hasItem grid (x + z) (y + (z *(-1)))		
 
diagonalsUp :: [[Int]] -> [[Int]]
diagonalsUp grid = filter (\x -> length x > 4) . map (\(x,y) -> diagonalUpwaysAt x y grid) $ (diagonalPositions grid)
 
diagonalUpValues = concatMap (windowed 4) (diagonalsUp grid)

In this case instead of incrementing our position by 1 on the x and y axes we needed to decrement our position on the y axis so it’d find the value one row above us.

To find the maximum product of 4 adjacent numbers in the grid we need to do the following:

problem_11 = maximum $ map product $ topToBottom ++ leftToRight ++ diagonalValues ++ diagonalUpValues
> problem_11
70600674

Obviously there’s a lot of duplication in this solution so another exercise for me is to try and make it a bit more concise!

I think I picked up this way of solving problems from playing around with clojure last year and it seems quite neat although I’m sure it might not seem that intuitive to someone who hadn’t seen it before.

The code for the whole solution is available as a gist.

Written by Mark Needham

March 13th, 2012 at 10:55 pm

Posted in Haskell

Tagged with ,

Functional C#: Continuation Passing Style

with 4 comments

Partly inspired by my colleague Alex Scordellis’ recent post about lambda passing style I spent some time trying out a continuation passing style style on some of the code in one of our controllers to see how different the code would look compared to its current top to bottom imperative style.

We had code similar to the following:

public ActionResult Submit(string id, FormCollection form)
{
	var shoppingBasket = CreateShoppingBasketFrom(id, form);
 
	if (!validator.IsValid(shoppingBasket, ModelState))
	{
	    return RedirectToAction("index", "ShoppingBasket", new { shoppingBasket.Id });
	}
	try
	{
	    shoppingBasket.User = userService.CreateAccountOrLogIn(shoppingBasket);
	}
	catch (NoAccountException)
	{
	    ModelState.AddModelError("Password", "User name/email address was incorrect - please re-enter");
	    return RedirectToAction("index", ""ShoppingBasket", new { Id = new Guid(id) });
	}
 
	UpdateShoppingBasket(shoppingBasket);
	return RedirectToAction("index", "Purchase", new { Id = shoppingBasket.Id });
}

The user selects some products that they want to buy and then just before they click to go through to the payment page we have the option for them to login if they are an existing user.

This code handles the server side validation of the shopping basket and tries to login the user. If it fails then we return to the original page with an error message. If not then we forward them to the payment page.

With a continuation passing style we move away from the imperative style of programming whereby we call a function, get a result and then do something with that result to a style where we call a function and pass it a continuation/block of code which represents the rest of the program. After it has calculated the result it should call the continuation.

If we apply that style to the above code we end up with the following:

public ActionResult Submit(string id, FormCollection form)
{
	var shoppingBasket = CreateShoppingBasketFrom(id, form);
	return IsValid(shoppingBasket, ModelState,
					() => RedirectToAction("index", "ShoppingBasket", new { shoppingBasket.Id} ),
					() => LoginUser(shoppingBasket, 
							() =>
								{
									ModelState.AddModelError("Password", "User name/email address was incorrect - please re-enter");
									return RedirectToAction("index", ""ShoppingBasket", new { Id = new Guid(id) });
								},
							user => 
								{
									shoppingBasket.User = user;
									UpdateShoppingBasket(shoppingBasket);
									return RedirectToAction("index", "Purchase", new { Id = shoppingBasket.Id });
								}));
}
 
 
private RedirectToRouteResult IsValid(ShoppingBasket shoppingBasket, ModelStateDictionary modelState, Func<RedirectToRouteResult> failureFn, Func<RedirectToRouteResult> successFn)
{
 
	return validator.IsValid(shoppingBasket, modelState) ? successFn() : failureFn();
}
 
private RedirectToRouteResult LoginUser(ShoppingBasket shoppingBasket, Func<RedirectToRouteResult> failureFn, Func<User,RedirectToRouteResult> successFn)
{
	User user = null;
	try
	{
	    user = userService.CreateAccountOrLogIn(shoppingBasket);
	}
 
	catch (NoAccountException)
	{
		return failureFn();
	}
 
	return successFn(user);
}

The common theme in this code seemed to be that there we both success and failure paths for the code to follow depending on the result of a function so I passed in both success and failure continuations.

I quite like the fact that the try/catch block is no longer in the main method and the different things that are happening in this code now seem grouped together more than they were before.

In general though the way that I read the code doesn’t seem that different.

Instead of following the flow of logic in the code from top to bottom we just need to follow it from left to right instead and since that’s not as natural the code is more complicated than it was before.

I do understand how the code works more than I did before I started playing before this but I’m not yet convinced this is a better approach to designing code in C#.

Written by Mark Needham

March 19th, 2010 at 7:48 am

Posted in .NET

Tagged with ,

Functional C#: Writing a ‘partition’ function

with 12 comments

One of the more interesting higher order functions that I’ve come across while playing with F# is the partition function which is similar to the filter function except it returns the values which meet the predicate passed in as well as the ones which don’t.

I came across an interesting problem recently where we needed to do exactly this and had ended up taking a more imperative for each style approach to solve the problem because this function doesn’t exist in C# as far as I know.

In F# the function makes use of a tuple to do this so if we want to create the function in C# then we need to define a tuple object first.

public class Tuple<TFirst, TSecond>
{
	private readonly TFirst first;
	private readonly TSecond second;
 
	public Tuple(TFirst first, TSecond second)
	{
		this.first = first;
		this.second = second;
	}
 
	public TFirst First
	{
		get { return first; }
	}
 
	public TSecond Second
	{
		get { return second; }
	}
}
public static class IEnumerableExtensions
{
	public static Tuple<IEnumerable<T>, IEnumerable<T>> Partition<T>(this IEnumerable<T> enumerableOf, Func<T, bool> predicate)
	{
		var positives = enumerableOf.Where(predicate);
		var negatives = enumerableOf.Where(e => !predicate(e));
		return new Tuple<IEnumerable<T>, IEnumerable<T>>(positives, negatives);
 
	}
}

I’m not sure of the best way to write this function – at the moment we end up creating two iterators to cover the two different filters that we’re running over the collection which seems a bit strange.

In F# ‘partition’ is on List so the whole collection would be evaluated whereas in this case we’re still only evaluating each item as it’s needed so maybe there isn’t a way to do it without using two iterators.

If we wanted to use this function to get the evens and odds from a collection we could write the following code:

var evensAndOdds = Enumerable.Range(1, 10).Partition(x => x % 2 == 0);
 
var evens = evensAndOdds.First;
var odds = evensAndOdds.Second;

The other thing that’s nice about F# is that we can assign the result of the expression to two separate values in one go and I don’t know of a way to do that in C#.

let evens, odds = [1..10] |> List.partition (fun x -> x % 2 = 0)

We don’t need to have the intermediate variable ‘evensAndOdds’ which doesn’t really add much to the code.

I’d be interested in knowing if there’s a better way to do this than what I’m trying out.

Written by Mark Needham

February 1st, 2010 at 11:34 pm

Posted in .NET

Tagged with , ,

Book Club: Why noone uses functional languages (Philip Wadler)

with 3 comments

Our latest technical book club discussion was based around Philip Wadler’s paper ‘Why noone uses functional langauges‘ which he wrote in 1998. I came across this paper when reading some of the F# goals in the FAQs on the Microsoft website.

These are some of my thoughts and our discussion of the paper:

  • One of the points suggested in the paper is that functional languages aren’t used because of their lack of availability on machines but as Dave pointed out this doesn’t really seem to be such a big problem these days – certainly for F# I’ve found it relatively painless to get it setup and running and even for a language like Ruby people are happy to download and install it on their machines and it is also pretty much painless to do so.
  • Erik pointed us to an interesting article which suggests that functional programming can be very awkward for solving certain problems – I think this is definitely true to an extent although perhaps not as much as we might think. I am certainly seeing some benefit in an overall OO approach with some functional concepts mixed in which seems to strike a nice balance between code which is descriptive yet concise in places. I’m finding the problems that F# is useful for tend to be very data intensive in nature.
  • Matt Dunn pointed out that an e-commerce store written by Paul Graham, which he later sold to Yahoo, was actually written in Lisp – to me this would seem like the type of problem that wouldn’t be that well suited for a functional language but interestingly only part of the system was written in Lisp and the other part in C.

    Viaweb at first had two parts: the editor, written in Lisp, which people used to build their sites, and the ordering system, written in C, which handled orders. The first version was mostly Lisp, because the ordering system was small. Later we added two more modules, an image generator written in C, and a back-office manager written mostly in Perl.

  • The article also suggests that it takes a while for Java programmers to come to grips with functional programs – I would agree with this statement to an extent although one of the things I found really hard when first reading functional programs is the non descriptiveness of the variable names. It seems to be more idiomatic to make use of single letter variable names instead of something more descriptive which I would use in an imperative language.

    I’m intrigued as to whether this will change as more people use functional languages or whether this is just something we will need to get used to.

  • The author makes a very valid point with regards to the risk that a project manager would be taking if they decided to use a functional language for a project:

    If a manager chooses to use a functional language for a project and the project fails, then he or she will certainly be fired. If a manager chooses C++ and the project fails, then he or she has the defense that the same thing has happened to everyone else.

    I’m sure I remember a similar thing being said about the reluctance to make use of Ruby a couple of years ago – it’s something of a risk and human nature is often geared towards avoiding those!

  • I think the availability of libraries is probably very relevant even today – it helps F# a lot that we have access to all the .NET libraries and I imagine it’s also the same for Scala with the Java libraries. I don’t know a lot about the Lisp world but I’m told that people often end up rolling their own libraries for some quite basic things since there aren’t standard libraries available as there are in some other languages.
  • Another paper pointed out as being a good one to read was ‘Functional Programming For The Rest Of Us‘ – I haven’t read it yet but it does look quite lengthy! Wes Dyer also has a couple of articles which I found interesting – one around thinking functionally and the other around how functional programming can fit in a mixed programming environment

I think in general a lot of the points this paper raises have been addressed by some of the functional languages which are gaining prominence more recently – Erlang, F# and Scala to name a few.

It will definitely be interesting to see what role functional languages have to play in the polyglot programming era that my colleague Neal Ford foresees.

Written by Mark Needham

July 8th, 2009 at 12:29 am

Functional Collection Parameters: A different way of thinking about collections

without comments

One of the changes that I’ve noticed in my coding now compared to around 7 or 8 months ago is that whenever there’s some operations to be performed on a collection I am far more inclined to think of how to do those operations using a functional approach.

I’ve written previously about the ways I’ve been making use of functional collection parameters in my code but what I hadn’t really considered was that the way of thinking about the problem we want to solve is slightly different.

While Dean and I were talking through the refactoring that I mentioned in my post about handling null collections, we realised that the way it was originally written followed a very sequential mindset.

public IEnumerable<Foo> MapFooMessages(IEnumerable<FooMessage> fooMessages)
{
	var result = new List<Foo>();
	if(fooMessages != null)
	{
		foreach(var fooMessage in fooMessages)
		{
			result.Add(new Foo(fooMessage));
		}
	}
	return result;
}
  • Create a new collection
  • Take an existing collection
  • If it’s not null then iterate over the existing collection
  • Add each item to the new collection
  • Return the new collection

I find when I’m thinking about doing this type of code now my thought process is more focused towards the collection as a whole rather than about the individual items in the collection.

If I do want to only apply an operation on a subset of the collection then I need to first apply another function to the whole collection that filters the collection down. I find myself thinking about what I want to happen rather than how I want to do it – a declarative approach over an imperative one in summary.

One of the LINQ C# extension methods which I sometimes find myself abusing is the ‘ForEach’ one which I feel is used a lot more times than is necessary and often ends up with complicated lambda blocks inside it which could be avoided by using some of the other functions.

To give a very simple example of some code I came across recently:

public IEnumerable<string> GetFooKeys(IEnumerable<Foo> foos)
{
	var list = new List<string>();
	foos.Where(foo => foo.Opted).ToList().ForEach(foo => list.Add(foo.Key));
	return list;
}

We are making use of functional collection parameters but we can easily do this without using the ‘ForEach’ method:

public IEnumerable<string> GetFooKeys(IEnumerable<Foo> foos)
{
	return foos.Where(foo => foo.Opted).Select(foo => foo.Key);
}

I think the danger with ‘ForEach’ is that we are creating side effects which may be unexpected. In this case there’s not really that much problem as we’re just adding a value to a list but it is possible to do anything else in the ForEach block as well.

I also came across a good post written by one of the 8th light guys talking about the use of ForEach in Scala and how we can use it in a way that minimises side effects.

Written by Mark Needham

June 18th, 2009 at 6:31 pm

Functional Collection Parameters: Handling the null collection

with 5 comments

One of the interesting cases where I’ve noticed we tend to avoid functional collection parameters in our code base is when there’s the possibility of the collection being null.

The code is on the boundary of our application’s interaction with another service so it is actually a valid scenario that we could receive a null collection.

When using extension methods, although we wouldn’t get a null pointer exception by calling one on a null collection, we would get a ‘source is null’ exception when the expression is evaluated so we need to protect ourself against this.

As a result of defending against this scenario we have quite a lot of code that looks like this:

public IEnumerable<Foo> MapFooMessages(IEnumerable<FooMessage> fooMessages)
{
	var result = new List<Foo>();
	if(fooMessagaes != null)
	{
		foreach(var fooMessage in fooMessages)
		{
			result.Add(new Foo(fooMessage));
		}
	}
	return result;
}

The method that we want to apply here is ‘Select’ and even though we can’t just apply that directly to the collection we can still make use of it.

private IEnumerable<Foo> MapFooMessages(IEnumerable<FooMessage> fooMessages)
{
	if(fooMessages == null) return new List<Foo>();
	return fooMessages.Select(eachFooMessage => new Foo(eachFooMessage));
}

There’s still duplication doing it this way though so I pulled it up into a ‘SafeSelect’ extension method:

public static class ICollectionExtensions
{
       public static IEnumerable<TResult> SafeSelect<TSource, TResult>(this IEnumerable<TSource> source, Func<TSource, TResult> selector)
       {
               return source == null ? new List<TResult>() : source.Select(selector) ;
       }
}

We can then make use of this extension method like so:

private IEnumerable<Foo> MapFooMessages(IEnumerable<FooMessage> fooMessages)
{
	return fooMessages.SafeSelect(eachFooMessage => new Foo(fooMessage));
}

The extension method is a bit different to the original way that we did this as I’m not explicitly converting the result into a list at the end which means that it will only be evaluated when the data is actually needed.

In this particular case I don’t think that decision will have a big impact but it’s something interesting to keep in mind.

Written by Mark Needham

June 16th, 2009 at 8:29 pm

OO with a bit of functional mixed in

with 2 comments

From my experiences playing around with F# and doing a bit of functional C# I’m beginning to think that the combination of functional and object oriented programming actually results in code which I think is more expressive and easy to work with than code written only with an object oriented approach in mind.

I’m also finding it much more fun to write code this way!

In a recent post Dean Wampler questions whether the supremacy of object oriented programming is over before going on to suggest that the future is probably going to be a mix of functional programming and object oriented programming.

I agree with his conclusion but there are some things Dean talks about which I don’t really understand:

The problem is that there is never a stable, clear object model in applications any more. What constitutes a BankAccount or Customer or whatever is fluid. It changes with each iteration. It’s different from one subsystem to another even within the same iteration! I see a lot of misfit object models that try to be all things to all people, so they are bloated and the teams that own them can’t be agile. The other extreme is “balkanization”, where each subsystem has its own model. We tend to think the latter case is bad. However, is lean and mean, but non-standard, worse than bloated, yet standardized?

I don’t think an object model needs to be stable – for me the whole point is to iterate it until we get something that fits the domain that we’re working in.

I’m not sure who thinks it’s bad for each subsystem to have its own model – this is certainly an approach that I think is quite useful. Having the same model across different subsystems makes our life significantly more difficult. There are several solutions for this outlined in Domain Driven Design.

Dean goes on to suggest that in a lot of applications data is just data and that having that data wrapped in objects doesn’t add much value.

I’ve worked on some projects which took that approach and I found the opposite to be true – if we have some data in an application it is very likely that there is going to be some sort of behaviour associated to it, meaning that it more than likely represents some concept in the business domain. I find it much easier to communicate with team mates about domain concepts if they’re represented explicitly as an object instead of just as a hash map of data for example.

Creating objects also helps manage the complexity by hiding information and from my experience it’s much easier to make changes in our code base when we’ve managed data & behaviour in this manner.

I think there is still a place for the functional programming approach though. Functional collection parameters for example are an excellent way to reduce accidental complexity in our code and removing useless state from our applications when performing operations on collections.

I don’t think using this type of approach to coding necessarily means that we need to expose the state of our objects though – we can still make use of these language features within our objects.

The most interesting thing for me about using this approach to some areas areas of coding when using C# is that you do need to change your mindset about how to solve a problem.

I typically solve problems with a procedural mindset where you just consider the next step you need to take sequentially to solve the problem. This can end up leading to quite verbose solutions.

The functional mindset seems to be more about considering the problem as a whole and then working out how we can simplify that problem from the outside in which is a bit of a paradigm shift. I don’t think I’ve completely made but it can certainly lead to solutions which are much easier to understand.

The other idea of functional programming that I’ve been experimenting with is that of trying to keep objects as immutable as possible. This pretty much means that every operation that I perform on an object which would previously mutate the object now returns a new instance of it.

This is much easier in F# than in C# where you end up writing quite a lot of extra code to make that possible and can be a bit confusing if you’re not used to that approach.

Sadek Drobi did a presentation at QCon London where he spoke more about taking a functional programming approach on a C# project and while he’s gone further than I have with the functional approach my current thinking is that we should model our domain and manage complexity with objects but when it comes to solving problems within those objects which are more algorithmic in nature the functional approach works better.

Written by Mark Needham

April 25th, 2009 at 11:14 am

Posted in OOP

Tagged with ,