Object Calisthenics Refactoring Dojo
Download as PPTX, PDF1 like4,105 views
The document outlines the rules of "Object Calisthenics", which are programming techniques to improve code quality. The rules include: limiting indentation levels, avoiding else keywords, wrapping primitives, using first class collections, limiting dots per line, avoiding abbreviations, keeping entities small with size limits, restricting instance variables, and avoiding getters/setters. The coding sessions involve pair programming, test-driven development, and retrospectives.
![One level of indentation per method
class Board {
...
String board() {
StringBuffer buf = new StringBuffer();
for (int i = 0; i < 10; i++) {
for (int j = 0; j < 10; j++)
buf.append(data[i][j]);
buf.append(“n”);
}
return buf.toString();
}
}](https://image.slidesharecdn.com/cdobjectcalisthenics-120624084147-phpapp01/85/Object-Calisthenics-Refactoring-Dojo-7-320.jpg)
Object Calisthenics Refactoring Dojo
- 3. Coding Dojo • Working in pairs • TDD (Red, Green, Refactor) • Doing something you can’t comfortably do (yet) • Slowly
- 4. Format • 45 minute session • Lunch • 45 minute session • Retrospective
- 5. The Problem
- 6. The Rules…
- 7. One level of indentation per method class Board { ... String board() { StringBuffer buf = new StringBuffer(); for (int i = 0; i < 10; i++) { for (int j = 0; j < 10; j++) buf.append(data[i][j]); buf.append(“n”); } return buf.toString(); } }
- 8. One level of indentation per method class Board { ... String board() { StringBuffer buf = new StringBuffer(); collectRows(buf); return buf.toString(); } }
- 9. Don’t use the ELSE keyword if (status == DONE) { doSomething(); } else { … Think of polymorphism, Null objects
- 10. Wrap all primitives and Strings public void addHours(int hours); public void add(HourDuration hours); currentTime.addHours(2); vs. HourDuration twoHours = new HourDuration (2); currentTime.add(twoHours);
- 11. First class collections Any class that contains a collection should contain no other member variables.
- 12. One dot per line • Law of Demeter game.getRow(1).countCrosses(); vs game.crossesForRow(1);
- 13. Don’t abbreviate • Why do we abbreviate in the first place? – Repetition? – Names too long? – Duplication of context?
- 14. Keep all entities small • No classes over 50 lines • No packages over 10 files (should be easy)
- 15. No classes with more than two instance variables class Name { class Name { String first; Surname family; String middle; GivenNames given; String last; } } class Surname { would be decomposed String family; into two classes } thus=> class GivenNames { List<String> names; }
- 16. No classes with more than two instance variables class Name { class Name { String first; Surname family; String middle; GivenNames given; String last; } } class Surname { would be decomposed String family; into two classes } thus=> class GivenNames { List<String> names; }
- 18. The Rules! 1. One level of indentation per method 2. Don’t use the ELSE keyword 3. Wrap all primitives and Strings 4. First class collections 5. One dot per line 6. Don’t abbreviate 7. Keep all entities small 8. No classes with more than two instance variables 9. No getters/setters/properties