Recently I ran a session on Object Calisthenics. I was first exposed to this challenge a few years ago and personally found it a fun, yet difficult experience. This is intentional as the challenge is designed to push the boundaries of best practices. The instructions are simple, there are nine rules to follow that must be obeyed during a traditional kata. We chose the Checkout Kata as the backdrop for this session. The teams feedback is as follows.
Use only one level of indentation per method
The team found this easy, and we discussed that following this to some degree in day to day development would be beneficial. Limiting the amount of nested code you have can improve readability quite substantially.
Don’t use the else keyword
At first this seemed a no brainier, until people realised it meant to favour polymorphism and not simply relying on an early return (implicit else).
Wrap all primitives and strings
The team managed well with this, one example would be a pair introduced an SKU (Stock Keeping Unit) to encapsulate a string and price. We do this well in day to day development at Codeweavers for domain objects, however we tend to fail in other areas such as data access code. This is one concept we need to try and improve at.
Use only one dot per line
The Law of Demeter in action. Once we cleared up the ideas behind this it was pretty easy for the teams to follow. This is not a dot counting exercise, so it is worth being familiar with the “law”. Much of our code would satisfy this requirement.
One controversial point that came up from this was regarding the team who chose SKU as a class name. Some of the team disagreed with this naming, though in terms of the domain (a supermarket) this is a perfectly valid name, therefore this did not break the rule. On the whole our code is named well, though our legacy codebases have many abbreviations that can confuse and obfuscate the intent of the code.
Keep all entities small
For new code, this is not an issue, however we find legacy code is given less treatment in regards to the size of our entities. This is something we should try to improve, though the teams found this easy enough during the kata.
Don’t use any classes with more than two instance variables
Personally I find this an odd requirement, providing you keep your classes small as per the previous requirement this tends to be a less relevant task. Of all the rules to follow, this is the one I could not advocate during day to day development providing you keep your classes small.
Use first-class collections
My personal favourite of the rules to abide by, and one I have since adopted into day to day coding. First class collections can simplify, and make code easier to understand as well as maintain and optimize. We have numerous examples of this at play at Codeweavers, and we should try to increase the amount of custom collections we have, as opposed to relying on primitive collections. For example, quotes is a better object than a array of quote.
Don’t use any getters/setters/properties
The hardest of all the rules to follow. Most of the teams tried to get past this rule by simply naming their getters/setters slightly differently. At the end of the day, there were still exposing state unnecessarily. We would never try to enforce such a rule for general development, but for core business logic this principle actually makes sense. The areas where this falls down, is on the boundary of the system, for example user input or output would be such scenarios where getters/setters are the easiest, cleanest solutions. Each team found this requirement the hardest to work with, which mimics my first expose to the object calisthenics challenge.