OOP is obviously nothing new and has been around for a long time. However, even if we learn and understand these concepts, do you really think we're implementing these properly in code?

1. Object Calisthenics
by Taki Bacalso

2. Before we start...
We are all quite aware what core concepts make up good
OO code…
cohesion, loose coupling, no redundancy, encapsulation,
testability, etc.
However, are we really implementing these concepts
properly in code?

3. Coding is like Drawing...
Drawing process...
Expectation Reality

4. Not exactly what you had in mind...
Source: http://www.funnyjunk.com/funny_pictures/4574195/Drawing+expectations+vs+reality

5. “It’s one thing to understand that encapsulation
means hiding data, implementation, type, design, or
construction. It’s another thing altogether to design
code that implements encapsulation well.”
- Jeff Bay

6. Object Calisthenics
“physical exercises that are done without special equipment”
source: Merriam-Webster
coined by Jeff Bay in :
“The Thoughtworks Anthology”
Is a group of guidelines that promotes
good object-oriented design.

7. The Challenge...
so pick the ones that work for you 9
Far stricter coding standards than
you’ve ever used in your life.
Not universally applicable to all
programming languages.
Leggo!

8. Use only one level of indentation
per method
1st Rule of thumb

10. Basically...
● Do one thing per method
○ one control structure
○ one block of statements
● Avoid Nested Control Structures
○ it means you’re doing more than one thing

11. √ Do one thing per method
√ Reusable code

12. Benefits
● Level of reuse will start to rise
exponentially
● Easier to debug these ‘code snippets’

13. Don’t Use the else keyword
2nd Rule of thumb

15. Basically...
● Nested conditionals and long case statements are
hard to follow
● Easy to add branch in existing conditional
○ ...rather than refactoring to a better solution
● Frequent source of Code Duplication

16. How to Fix...
● return Early
● Use Polymorphism
● See Refactoring Methods:
○ Replace Type Code with State/Strategy
○ Replace Conditional with Polymorphism
○ Introduce Null Object

19. Wrap all primitives and strings
3rd Rule of thumb

21. Basically...
● Bad: Method names do all the work of expressing the
intent
● Primitive variables
○ Don’t help write semantically correct programs
● Apply if objects need behavior or for a group of
primitives

23. Benefits...
● More maintainable code
● Type Hinting
○ benefits both compiler and programmer
● Context of value is more obvious
● Avoids Primitive Obsession Code Smell

24. Use only one dot per line
4th Rule of thumb

26. Basically...
● Multiple dots (Nested Calls)
○ indicate misplaced responsibilities
○ violate encapsulation
● Ask an object to do something for you
○ Not poke around its insides!
● Law of Demeter
○ “Talk only to your friends”

27. Don’t Abbreviate
5th Rule of thumb

28. Basically...
● Confusing - tend to hide larger problems
● Keep names to one-two words
○ class names
○ method names
○ entities
● Avoid names that duplicate context
○ bad: [order shipOrder] ✘
○ good: [order ship] ✔

29. Keep all entities small
6th Rule of thumb

30. Basically...
● No class more than 50 lines
● No package more than ten files
● Why 50 lines?
○ Visible on screen without scrolling
○ easier to grasp quickly

31. Don’t use any classes with more
than two instance variables
7th Rule of thumb

33. Basically...
● Forms 2 Kinds of classes, those that:
○ maintain the state of a single instance variable
○ coordinate two separate variables
● Don’t mix these 2 responsibilities!

35. Use First-Class Collections
8th Rule of thumb

36. Basically...
● Any class that contains a collection should contain no
other member variables
● Class will contain related behaviors (i.e filters)
● Use when collection has behavior
● Implemented by NSArrays, NSSets, etc.

37. Don’t use any
getters/setters/properties
9th Rule of thumb

38. Basically...
● Stated as, “Tell, don’t ask”
● Don’t expose private variables
● Please do use these to handle
retains/releases

39. In Conclusion, they aim
● to visualize and implement the encapsulation of data
● to use polymorphism appropriately
● to encourage concise and straightforward naming
standards
● to craft code that has no duplication in code or idea

40. The Real Challenge

41. Try It!
Write a 1000 line program that follow 100%
of these rules

42. You will find yourself
● Breaking old habits
● Changing rules that you may have lived with for
your whole programming life
● Creating something completely different from
what you expected

43. Overall
“ The goal is code that concisely expresses simple
and elegant abstractions for the incidental
complexity we deal with all day long.”
- Jeff Bay

44. Try It and see what
happens :)
Thank you for listening! :D

45. References
“ThoughtWorks Anthology” by ThoughtWorks
“Object Calisthenics Applied to PHP” by Guilherme Blanco
“Your code sucks! let’s fix it” by Rafael Dohms
“Object Calisthenics: write better object-oriented code” by Fran Diéguez
http://www.bennadel.com/resources/uploads/2012/ObjectCalisthenics.pdf