I was coding for maybe 4 or 5 hours and checked in about 120 times which is far more frequently than I would do normally although perhaps it shouldn’t be.
I thought it would be quite distracting to have to check in that often but the checkin messages ended up becoming a stream of consciousness of what I was thinking which proved quite useful on a few occasions when I got side tracked a bit and retraced my steps in the history to find out what I was supposed to be doing - Git was pretty much acting as my sounding board since I didn’t have a pair to work with on this exercise. I’d definitely try this out again and as I’ve mentioned a few times I want to try it out in a coding dojo some time.

While trying to remove some duplication that had worked its way into the code I realised that the template method would be the easiest way to remove that duplication and as I mentioned in an earlier post, having functions/actions in C# makes the implementation of this pattern a bit simpler: _~csharp public abstract class ThrowBase : IThrow { private readonly Func<IThrow, bool> beatenBy; protected ThrowBase(Func<IThrow, bool> beatenBy) { this.beatenBy = beatenBy; } .... public bool Beats(IThrow aThrow) { return IsDifferentThrowTo(aThrow) && !beatenBy(aThrow); } } } _{~ ~}csharp public class Scissors : ThrowBase { public Scissors() : base(weapon => weapon.BeatsScissors()) { } ... } _~ If we didn’t have functions then we’d need a method on 'ThrowBase' which we would need to implement in each of its sub classes. As it is we can just pass a function into the constructor which does the same job.

Another thing I found quite interesting about this exercise was that I was seeing more easily where methods didn’t seem to belong on an existing object and I ended up creating a new object which described the interaction - chatting about the code with Liz she pointed out that I was probably creating domain events which we had discussed a few days earlier in book club. Once I started thinking about this interactions as 'domain events' the naming of them seemed to be much more obvious - for example after this conversation with Liz I realised that the interaction between two 'Throws' would be a 'ThrowDown' and that there would probably be a 'ThrowDownAdjudicator' to decide the outcome of a 'ThrowDown'.

I found it quite difficult to follow the rules of the exercise when I realised that I wanted to return a 'ThrowDownResult' which would indicate whether there was a winner for a 'ThrowDown' and if so who it was. I couldn’t see a way to write all of this code in the test since I had already created the class previously so I ended up writing this code straight onto the class. I think I probably extracted to a class too early on some occasions instead of waiting for a more complete version of a method to be written before moving it. Next time I think I’d wait until I’d completed all the examples /tests I want to write around a particular method before moving it onto a class.