OrthoCoders

You can code it, I can help!

The Bowling Game Kata - First Attempt

Last week I did a presentation about the Bowling Game kata in C#. I created a repository on GitHub with the code so I can share my first attempt. You can follow the commit comments to get an idea of the train of thought. Or if u prefer, just keep reading :)

The Methodology

I used TDD and somehow BDD all the way. Started with an acceptance test and jumped in and out from the unit tests until the feature passed. Why is a good idea to start with an acceptance test? When you know where you want to go, what you want to achieve, is easier to keep the focus. Having a way of identifying if the current feature is finished is a lot of power in your hands, so do the minimum necessary to make it work and then - once the test is passing - do refactoring as you see fit. In the solution you will find three projects:
  1. BowlingKata: Classes that implement the Kata
  2. BowlingKata.Unit.Tests: Unit tests
  3. BowlingKata.Acceptance.Test: Features that I'm looking for in a bowling game

Design Decisions (fast forward TDD)

As soon as I started to write a unit test for the BowlingGame class I wonder how am I going to design the solution. My first test was for the method Roll(pins). And right there I had to assign responsibilities. What should this method do? Do the "registration" only? Do the calculation as well? Is there any other class involved? I decided on keep things simple and separate two clear responsibilities:
  1. Keeping the number of pins knocked down on each ball (or frames later)
  2. Calculating the score based on the information on each frame
So I created two interfaces with that purpose:
  • IFrameKeeper: In charge of registering the pins down in each frame
  • IScoreCalculator: in charge of calculating the score over a sequence of frames (10 frames + 1 optional extra)
You can follow all the tests to see how the interfaces grew in complexity to fullfil the intended responsibility.

What's next?

After the first approach I thought that would be nice to refactor again and explore other solutions:
  • Change the frame class IBowlingFrame to be able to calculate the score, maybe having regular frames, spare, and strike.
  • Find a way of registering the pins and also add some kind of bonus to avoid the iteration over the frames to get the score
Which option did you implement? Please share!
Feedback is more than welcome.