Several years ago, Brian Kotek introduced me to the concept of Object Calisthenics. Object Calisthenics is an exercise defined by Jeff Bay to help programmers think very critically about their application design choices in an object-oriented context. I attempted this exercise a long time ago; but, I was quickly flustered by my lack of understanding. Now, a few more years of experience under my belt, I thought it would be an exciting exercise to try again. While I see myself as being very technically-capable in programming, I clearly lack a strong understanding of Object Oriented Programming (OOP). I'm hoping that this exercise will help me gain clarity and kick the bad habits that I have accumulated from years of procedural programming.
Some quick background information - what's the point of Object Calisthenics? Here is an excerpt from Jeff Bay's paper on the subject:
We've all seen poorly written code that's hard to understand, test, and maintain. Object-oriented programming promised to save us from our old procedural code, allowing us to write software incrementally, reusing as we go along. But sometimes it seems like we're just chasing down the same old complex, coupled designs in Java that we had in C.
Good object-oriented design is hard to learn. Transitioning from procedural development to object-oriented design requires a major shift in thinking that is more difficult than it seems. Many developers assume they're doing a good job with OO design, when in reality they're unconsciously stuck in old habits that are hard to break. It doesn't help that many examples and best practices (even Sun's code in the JDK) encourage poor OO design in the name of performance or simple weight of history.
The core concepts behind good design are well understood. Alan Shalloway has suggested that seven code qualities matter: cohesion, loose coupling, no redundancy, encapsulation, testability, readability, and focus. Yet it's hard to put those concepts into practice. 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. So here's an exercise that can help you to internalize principles of good object-oriented design and actually use them in real life.
In the above PDF, Jeff Bay goes on to describe the 9 rules of Object Calisthenics:
- One level of indentation per method.
- Don't use the ELSE keyword.
- Wrap all primitives and Strings in classes.
- First class collections (no simple Arrays).
- One dot per line (don't violate the Law of Demeter).
- Don't abbreviate names.
- Keep all classes less than 50 lines.
- No classes with more than two instance variables.
- No getters or setters.
This sounds tough! But, that's what makes it exciting. For this exercise, I want to do something that is non-trivial; but, also something that is not so complex that it takes forever to finish it. After a few days of mulling over ideas, I decided to go with the concept of a "Match Maker" (as in, Relationships). This gives me the opportunity to look at polymorphism, collections, and behaviors.
To get started, I've created a GitHub repository for this exercise as I am sure it will require many iterations to get right. Very exciting! Wish me luck :D