4. The Nine Rules
1. Use 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 (one or twowords names)
6. Keep all entities small (50 lines/class, 10 classes/package)
7. Don't use any classes with more than two instance variables
8. Use first class collections
9. Don't use any getters, setters or properties
5. Bank Accounts Kata
Think of your personal bank account experience
When in doubt, go for the simplest solution
6. Features
Deposit, Withdrawal
Transfer
Account Statement (date, amount, balance)
Statement printing
Statement filters
7. You can start with
Bank Accounts Kata sample code
http://bit.ly/jtOP6F
if you need jodatime
http://bit.ly/kSpwNj
8. Wrap-up
Which rules:
were simplest to follow?
hardest?
had biggest impact on design?
you think you could use in production?
9. Rule 1: Use One Level of
Indentation per Method
Method > does exactly one thing
Reuse
Readability
Implementation matches name > easier to find bugs
10. Rule 2: Don't Use the else
Keyword
Simple cases > guard clauses, early returns
Complex cases > polymorphism (Strategy, Null Object)
11. Rule 3: Wrap All Primitives and
Strings
Express intent
Typesafe
Place for behaviour
12. Rule 4: Use Only One Dot per
Line
Place responsibilities properly
The Law of Demeter
your toys
toys that you make
toys someone gives you
14. Rule 6: Keep All Entities Small
Single Responsibility Principle
Cohesive packages
15. Rule 7: Don't Use Any Classes
with More Than Two Instance
Class cohesion
Variables
Find commonality of instance variables
Object Model decomposition
16. Rule 8: Use First-Class
Collections
Home for collectionrelated behaviour
17. Rule 9: Don't Use Any
Getters/Setters/Properties
Strong encapsulation boundaries
“Tell, don't ask”
18. References
Object Calisthenics, Jeff Bay in: The ThoughtWorks Anthology,
Pragmatic Bookshelf 2008.
Pics
http://www.flickr.com/photos/jiheffe/3462940215/
http://www.flickr.com/photos/singapore2010/4916726882