object calisthenics in objective-c
DESCRIPTION
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?TRANSCRIPT
Object Calisthenics
by Taki Bacalso
Before we start...
We are all quite aware what core concepts make up good OO code…
However, are we really implementing these concepts properly in code?
cohesion, loose coupling, no redundancy, encapsulation, testability, etc.
Coding is like Drawing...
Expectation Reality
Drawing process...
Not exactly what you had in mind...
Source: http://www.funnyjunk.com/funny_pictures/4574195/Drawing+expectations+vs+reality
“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
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.
The Challenge...
Far stricter coding standards than you’ve ever used in your life.
Not universally applicable to all programming languages.
so pick the ones that work for you
9Leggo!
1st Rule of thumb
Use only one level of indentation
per method
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
√ Do one thing per method√ Reusable code
Benefits
● Level of reuse will start to rise exponentially
● Easier to debug these ‘code snippets’
2nd Rule of thumb
Don’t Use the else keyword
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
How to Fix...
● return Early
● Use Polymorphism
● See Refactoring Methods:○ Replace Type Code with State/Strategy○ Replace Conditional with Polymorphism○ Introduce Null Object
3rd Rule of thumb
Wrap all primitives and strings
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
Benefits...
● More maintainable code
● Type Hinting○ benefits both compiler and programmer
● Context of value is more obvious
● Avoids Primitive Obsession Code Smell
4th Rule of thumb
Use only one dot per line
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”
5th Rule of thumb
Don’t Abbreviate
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] ✔
6th Rule of thumb
Keep all entities small
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
7th Rule of thumb
Don’t use any classes with more
than two instance variables
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!
8th Rule of thumb
Use First-Class Collections
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.
9th Rule of thumb
Don’t use any getters/setters/properties
Basically...
● Stated as, “Tell, don’t ask”
● Don’t expose private variables
● Please do use these to handle retains/releases
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
The Real Challenge
Try It!
Write a 1000 line program that follow 100% of these rules
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
Overall
“ The goal is code that concisely expresses simple and elegant abstractions for the incidental complexity we deal with all day long.”
- Jeff Bay
Thank you for listening! :D
Try It and see what
happens :)
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