This series of katas is based on building a banking application for managing customer accounts.
To be honest though, it’s probably unlike any application a bank would actually use, but it’s worth putting this objection to one side as it makes a useful vehicle for exploring an interesting set of programming problems.
Each kata starts from its own branch in the repository. The solution file in that branch has everything you need to get working on the kata straight away.
Each kata will ask you to implement a small set of features, which should take no more than an hour or two.
In this series we’re going have a go at using the ideas of Object Calisthenics in an application that is likely to have a reasonable amount of complexity. These boil down to a set of constraints on how we write code and aim to codify what are generally recognised to be good programming practices:
- Don’t write more than one level of indentation your code
- Don’t use the else keyword
- Wrap all primitive types and strings
- Use only first class collections
- Use no more than one dot per line
- Don’t abbreviate
- Keep all entities small
- Limit classes to no more than two fields
- No getters/setters/properties
Like many good programming practices, in a real environment we sometimes skirt around them when they become inconvenient. The idea of this series is to adhere to these rules even (or especially) when it’s inconvenient, with the view of seeing which of them we find to be useful as the application grows in complexity. By applying them to extremes here, we may learn more about which (if any) are good to apply rigorously in our day-to-day programming, and which we can be more relaxed about.
Before starting, it’s important to have a good grasp of each rule and why it’s thought to be helpful, so take a few minutes to read through the introduction to Object Calisthenics.