Archive for April 2011
Last month we had a coding dojo on a user group meeting in Ratingen. This was the first coding dojo for most of the user group members and I was allowed to facilitate it. As a big fan of Ilker’s style coding dojos for his entertaining talent I wanted to deliver an energizing experience to the attendees if anything at all. So instead of throwing people at kata right away and watching them arguing which unit-testing framework to use I decided make a “demo of a coding dojo”.
Imagine yourself sitting in a racing car having never seen a race and knowing only how to ride a bicycle. Now go on and have fun on a track. Two hours later you already can start the engine and release the handbrake. Was it fun? Will you come next time to learn how to shift gears? I doubt. Now Imagine somebody took you for a drifty ride. Now it makes sense! Now there is even a point to learn it yourself. The same way I learned to love coding katas: by watching masters (like this one) doing them.
I choose a modified version of the String Calculator Kata: instead of just adding numbers joined to a string, I aimed to implement an arithmetic expression evaluator (“1 + 2” –> 3). My tools for this kata included VS2010, C#, Resharper, xunit.net as testing framework, and Should as a fluent assertions library.
The thing I like most about TDD is that the whole software design emerges out of a consequence of simple decisions. Each design is unique and none is the right one. You can follow my implementation on Github, I’ll just list here most noticeable steps:
The first feature was to evaluate a decimal constant. The simple “double.Parse(expression)” method did the trick.
The next one was a simple addition. The “string.Split(‘+’)” is obvious to extract the arguments of addition, the next step is however that same little design decision that defined the whole solution. Instead of manually juggling array indices I used my favorite .NET API – Linq. So, to add the arguments from a string array I wrote the following:
.Select(x => double.Parse(x))
.Aggregate((a, b) => a + b);
Now implementing multiplication was analogous. The resulting code duplication was an obvious smell though. I always forget those fancy functional slang, but the point was to effectively build a pipeline of functions, where each function is applied to the result of the next one in the pipeline. Then the only thing to do is to call that pipeline as a function and pass it the original string expression. The whole solution looks like this:
public class Calculator
private static readonly Func<string, double> Parse = double.Parse;
private static readonly Func<string, double> Pipeline = Parse
.Wrap(‘*’, (a, b) => a*b)
.Wrap(‘/’, (a, b) => a/b)
.Wrap(‘+’, (a, b) => a + b)
.Wrap(‘-’, (a, b) => a – b)
public double Evaluate(string expression)
public static class PipelineExtensions
public static Func<string, double> Wrap(
this Func<string, double> inner,
Func<double, double, double> aggregate)
return expression => expression
It definitely doesn’t take parenthesis into account, but it quite elegantly solves four arithmetic operations with operator precedence and more than two arguments and more than one operator per expression. Without using Linq I would probably go with a bunch of if/else statements being than refactored into an expression parser and an expression tree evaluator (which is a way to go for supporting parenthesis). Anyway for the first iteration I implemented all the features I wanted and ended up with very little code, which I don’t mind to throw away if it doesn’t fit anymore. And this is a true virtue of TDD.