Object Calisthenics - A fresh look on OO Programming

Object Calisthenics is an exercise on object oriented programming introduced by Jeff Bay where 9 simple rules can help you go back to basics and revisit object oriented programming through a new perspective, more like a code kata rather than absolute principles.

Transcript

1. Object Calisthenics Samuel Gordalina @sgordalina
3. Calisthenics calisthenics (n): derived from the greek term, exercise, under the gymnastics context @sgordalina
4. What are Object Calisthenics? @sgordalina
5. What are Object Calisthenics? Jeff Bay listed 9 rules to writing better Object Oriented Code @sgordalina
6. Why? @sgordalina
7. Code should be •Readable •Comprehensible •Testable •Maintainable @sgordalina
8. Rules @sgordalina
9. 1 Only one level of indentation per method @sgordalina
10. 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(); } } @sgordalina
11. class Board { // ... String board() { StringBuffer buf = new StringBuffer(); collectRows(buf); return buf.toString(); } void collectRows(StringBuffer buf) { for(int i = 0; i < 10; i++) collectRow(buf, i); } void collectRow(StringBuffer buf, int row) { for(int i = 0; i < 10; i++) buf.append(data[row][i]); buf.append("\n"); } } @sgordalina
12. 2 Don’t use the ELSE keyword @sgordalina
13. class Board { // ... String board(StringBuffer buf) { if (buf.length()) { return buf.toString(); } else { collectRows(buf); return buf.toString(); } } // ... } @sgordalina
14. class Board { // ... String board(StringBuffer buf) { if (!buf.length()) { collectRows(buf); } return buf.toString(); } // ... } @sgordalina
15. It is hard to let go •ELSE is resident in our consciousness •Come up with other alternatives @sgordalina
16. 3 Wrap all primitives and Strings @sgordalina
17. Small objects make you write semantically correct programs as well as feeding the compiler additional info about what it is (static analysis) @sgordalina
18. Not possible in languages which are not completely object oriented (e.g.: PHP) which degrades performance @sgordalina
19. However @sgordalina
20. If the primitive type has a behavior it should be encapsulated @sgordalina
21. class UIComponent { void repaint(boolean animate) { // ... } } // ... component.repaint(true); @sgordalina
22. class Animate { Animate(boolean animate) { this.animate = animate; } } class UIComponent { // ... void repaint(Animate animate) { // ... } } // ... component.repaint(new Animate(true)); @sgordalina
23. 4 First class collections @sgordalina
24. Any class that contains a collection should contain no other member variables Java Collections follow this rule @sgordalina
25. 5 One dot per line Arrow in PHP @sgordalina
26. If you are digging into other object’s properties or methods you are probably violating encapsulation @sgordalina
27. The Law of Demeter “Only talk to your friends” is a good place to start refactoring @sgordalina
28. class Board { // ... class Piece { // ... String representation; } class Location { // ... Piece current; } String boardRepresentation() { StringBuffer buf = new StringBuffer(); for(Location l : squares()) buf.append(l.current.representation.substring(0, 1)); return buf.toString(); } } @sgordalina
29. class Board { class Piece { private String representation; String character() { return representation.substring(0, 1); } void addTo(StringBuffer buf) { buf.append(character()); } } class Location { private Piece current; void addTo(StringBuffer buf) { current.addTo(buf); } } String boardRepresentation() { StringBuffer buf = new StringBuffer(); for(Location l : squares()) l.addTo(buf); return buf.toString(); } } @sgordalina
30. 6 Do not abbreviate @sgordalina
31. Why should you abbreviate? @sgordalina
32. Abbreviations can be confusing and tend to hide larger problems @sgordalina
33. If you have to write the same name repeatedly, you are probably reusing it multiple times, signaling a code duplication @sgordalina
34. Method name is too long? Maybe your class has multiple responsibilities you should probably rethink your architecture. @sgordalina
35. 7 Keep your entities small @sgordalina
36. No class over 50 lines No package over 10 files @sgordalina
37. Keeping entities small forces them to have a single purpose and a real identity @sgordalina
38. 8 No classes with more than two instance variables @sgordalina
39. “Most classes should simply be responsible for handling a single state variable, but there are a few that will require two.” - Jeff Bay @sgordalina
40. class Name { String first; String middle; String last; } @sgordalina
41. class Name { Surname family; GivenNames given; } class Surname { String family; } class GivenNames { List<String> names; } @sgordalina
42. Decomposition of object attributes leads to a more effective object model, one that represents a hierarchy of collaborating objects @sgordalina
43. 9 No getters/setters to properties @sgordalina
44. “Tell, don’t ask” @sgordalina
45. Tell your objects what to do instead of asking for their state. @sgordalina
46. Probably the hardest rule to follow, but the most brain picking one. One needs to rethink the way code is written @sgordalina
47. Conclusion @sgordalina
48. Object Calisthenics is more of a code kata rather than a philosophy @sgordalina
49. There is no One True OO Style™ @sgordalina
50. That which obscures my code is bad @sgordalina
51. Questions? @sgordalina
52. Thanks! Feedback: http://joind.in/talk/view/10022 @sgordalina