Mark Needham

We ran an Object Calisthenics variation of Coding Dojo on Wednesday night as part of ThoughtWorks Geek Night in Sydney.

Object Calisthenics is an idea suggest by Jeff Bay in The ThoughtWorks Anthology , and lists 9 rules to writing better Object Oriented code. For those who haven't seen the book, the 9 rules are:

1. Use only one level of indentation per method
2. Don't use the else keyword
3. Wrap all primitives and strings
4. Use only one dot per line
5. Don't abbreviate
6. Keep all entities small
7. Don't use any classes with more than two instance variables
8. Use first-class collections
9. Don't use any getters/setters/properties

We decided to try and solve the Bowling Game Problem while applying these rules. We coded in Java as this was a language everyone in the room was comfortable with. It would have been cool to try out Ruby or another language but I'm not sure if this type of setting is the best place to learn a new language from scratch.

I hadn't arranged a projector so we couldn't adopt the Randori approach. Instead we split into three pairs rotating every half an hour, discussing how each pair was approaching the problem at each change.

Learning from the problem

I was surprised how difficult the problem was to solve using the Object Calisthenics rules. There were several occasions when it would have been really ease to expose some state by introducing a getter but we had to try another way to attack the problem.

We have been following the approach of wrapping all primitives and strings on my current project as 'micro types' so this rule wasn't new to me but the general feeling early on was that it was quite annoying to have to do. From my experience on my project it does help to encourage a more object oriented approach of keeping the data with the behaviour.

This approach to object orientation is very extreme but the author suggests giving it a try on some small projects as being able to code like this will result in you seeing problems in a different way. I noticed today that I was always on the lookout for ways to ensure that we didn't expose any state so it's had a slight influence on my approach already.

We had an interesting discussion about mid way through about whether we should implement equals and hashcode methods on objects just so that we can test their equality. My general feeling is that this is fine although it has been pointed out to me that doing this is actually adding production code just for a test and should be avoided unless we need to put the object into a HashMap or HashSet when the equals/hashcode methods are actually needed. The only alternative I can think of is to not test object equality and instead only test equality where we have primitives or to test for equality by using reflection.

From seeing the approaches others had taken I realised that the approach we took on my machine was too difficult – we would have been more successful by adopting baby steps.

Learning about the format

We initially started out trying to design a solution to the problem on a white board before getting to the coding but this didn't work particularly well so we abandoned this and went straight to the code.

Each machine had three different pairs working on the problem over the duration of the night, with one person always staying on the machine and the others rotating. While we all had slightly different approaches to the problem it would have been interesting to see if we could have progressed further using the Randori approach with everyone having input to the same code base.

None of the pairs managed to complete the problem, and there was concern that the problem was too big to fit into the 90 minutes we spent coding. After speaking with Danilo and reading his Coding Dojo paper it seems that this is not necessarily a bad thing and the focus is supposed to be more on the learning than problem completion.

It was certainly an interesting experience and I had the opportunity to work with some people that I haven't worked with before. We are hopefully going to make these Coding Dojos a regular feature and try out some different approaches to see which works best for us.

On this occasion I selected the problem but in the future we would look to make it a group based decision depending on what people are keen to learn.