In preparation for the upcoming session at the Houston TechFest (October 9th, 2010, UH campus), I’m doing “internet research” AKA browsing around a lot. I’m collecting here a list of everything I could find on the topic. Be warned, this will be exhaustive (and thus, exhausting to read). Apologies in advance.

 

The original essay

  • Object Calisthenics [warning: RTF document] by Jeff Bay – this also appears as a chapter in The Thoughtworks Anthology. It’s well-written, and if you’re going to bother trying out object calisthenics, please read the original essay. The most important thing to learn is not the rules themselves, but the reasons the rules exist, and thus, what you’re supposed to take away from the entire experience.

Retrospectives from people who have attempted object calisthenics

  • Object calisthenics: first thoughts by Mark Needham. Notable takeaways:
    • he was “surprised how difficult the problem was to solve using the Object Calisthenics rules.”
    • “I noticed [after trying object calisthenics] that I was always on the lookout for ways to ensure that we didn't expose any state, so it's had a slight influence on my approach already.”
    • Unit testing is hard:
      • Mark’s group implemented .Equals() and .ToHashCode() for the sole purpose of being able to unit test while adhering to the rules of object calisthenics. (It is generally frowned upon to implement production code for the sole purpose of building tests.)
      • Another group used baby steps TDD and triangulation to build unit test. While Mark (in the blog post) was supportive of this approach, I had less than stellar results trying this out in our coding dojo last year.
    • They didn’t finish solving the problem. For those of you surprised by this, trust me: if anyone ever finishes a problem in a coding dojo environment, it’s something of a miracle. So, with this context, you may read the sentence as “Today, no miracle occurred; we didn’t finish the problem during the coding dojo.”
    • Notes from the comments:
      • From Kris: Possibly encourage people solve a small part of the problem by breaking the rules, then, slowly refactor their code to “make the rules pass” in a manner conceptually similar to TDD’s red/green/refactor.
  • First Sydney Coding Dojo (NOTE: this is another perspective on the same dojo mentioned above by Mark Needham)
    • Coding dojos as a means of idea exchange: “Apart from being an amusing experience, it was quite interesting to see the different approaches that people take to solve the same problem, - the design, the way they write tests, the code style, pretty cool.”
    • Also interesting to note, the author suggested improvements that would “improve productivity.” Coding dojo productivity seems to ALWAYS be abysmal.
  • Object calisthenics: by example; inspected – quotes:
    • “…his techniques included the use of the Visitor design pattern, which wasn’t the author’s first choice beforehands. Test Driven Development alone wouldn’t have led to this solution…”
    • “The first observation was that the rules follow a dramatic composition that orders them from “most obvious and immediate code improvement” to “hardest to achieve code improvement” and in the same order from “easiest to acknowledge” to “most controversial”. At the end of the list, the audience rioted most of the time. But if you reject the last few rules, you’ve silently agreed to the first ones, the ones with the greatest potential for immediate improvement.”
    • “It’s a learning catalyst for those of us that aren’t born as programming super-heros. To speak in terms Kent Beck coined: Object Calisthenics provide some handy practices that might eventually lead to a better understanding of their underlying principles. Even beginners can follow the practices and review their code on compliance. When they fully get to know the principles (like Law Of Demeter, for example), they are already halfway there.”
    • This is yet another example of “coding dojos are a safe learning environment”: “At last, Object Calisthenics, if performed as a group exercise, can be a team solder. You can rant over code together without regrets – the rules were made elsewhere. And you can discuss different solutions without feeling pointless – fulfilling the rules is the common goal for a short time.”
  • Alt.Net Stockholm coding dojo – it appears that they didn’t finish the problem, no miracle occurred at this dojo either. The only other takeaway I have from this is that nobody wants to stick to the object calisthenics rules. My pet theory is that people try to avoid pain, and these rules cause a lot of thinking pain.
  • Trying Coding dojo, kata and Extreme OOP - “Second - the rules are very hard to follow… Very hard. We didn’t get quite there I felt.”
  • “Being Cellfish” – a Microsoft employee’s detailed experiences with object calisthenics:
    • Team Coding Dojo 5 -
      • On refactoring as a tool of emergent design: “This time we had a lot of design discussions and we had to force our selfs to just do some refactoring and see where it took us. I think it was great to see how we refactored and created new classes just to later refactor these classes to nothing and removing them. It was a great experience in how refactoring in steps reveals the design for you. We also had the full test suite save us a bunch of times from stupid bugs which is also nice.”
      • On lack of productivity: “But refactoring existing code to follow the object calisthenics rules is very hard and takes time.”
    • Object calisthenics: first contact
      • On small classes: “I also learned that classes that I felt were really small and doing only one thing actually could be split up when I had to in order to conform to the rules. Reminds me of when people thought atoms were the smallest building blocks of the universe and then it turned out to be something smaller...”
      • “So all in all I think doing a coding Kata while applying the object calisthenics rules will improve my ability to write object oriented code”

Explanations of object calisthenics

Problem sets/source code of object calisthenics attempts

Reviews from people who have read about (have not tried) object calisthenics

  • Object Calisthenics - “Jeff explains in a great way a few principles and challenges the reader to try them out in a rigorous way, just to see how it works out. This is a great way to present it, its not saying “I know the right way and you must follow the rules”, its suggesting that you should give it a chance and you might begin to see some rewards, or “Try it, you might like it”.”
  • Object Calisthenics, Part 2 – the author discusses how adding small methods eliminates what people sometimes call “micro duplication”, and discusses the purpose of rule #3 (No static methods other than factory methods) in further detail.
  • If this is object calisthenics, I think I’ll stay on the couch – from the comments: “…but if [object calisthenics is] an exercise, then you need to make sure that it’s working the right muscles, and not hurting your overall form. My belief is that these exercises are not working the right muscles.” My counter-argument to the author is: dude, you come from SmallTalk land. You have mastered the mama bear, (just-right!) approach to object-oriented programming. Object calisthenics was written by a Java programmer, for the (presumably) Java audience. Think of object calisthenics as the papa bear object-oriented ruleset (too hot!) to counteract the standard baby bear procedural-style programming practice (too cold!) . Once the baby bear programmers have tried the papa bear’s porridge, they’ll…well…I sure hope they learn something. Anyway, this article has good points
  • OO’s short classes and small methods – while the author endorses object calisthenics, I’m hesitant to quote him on anything, as he hasn’t tried them out. In any event, this article was linked from proggit and received lots of comments with a mix between those expressing dubiousness, comments defending the “just try it” approach, and comments completely misrepresenting the object calisthenics rules. The reddit comment thread is similar. Takeaway for me is, first, emphasize that the rules make sense, and second, have a paper reference explaining the rules in further detail. There will be misunderstanding, guaranteed.

JACKPOT! Blog post citing research from SCIENCE! SCIENCE, whereupon we can base our opinions, as opposed to basing our opinions on other uninformed blog posts! ggggggggggggggggggggggg-yes!

  • Are short methods actually worse? – the author reviews the most commonly cited research on method length (make sure to read the update for the updated conclusion). The author also (separately, not influenced by the aforementioned research) introduces a concept I can agree with: “By making your methods shorter, you’re just trading one kind of complexity for another.” This I think is the #1 issue keeping people from adopting object-oriented programming and the “explosion of objects”—they can no longer find their code once it’s split between five objects, instead of the one object that did EVERYTHING.

Related links

  • Ravioli Code (from the original gangster C2 wiki) – spaghetti is what happens when you have a procedural mess. Ravioli is what happens when you have an object-oriented mess. In defense of XP, (next link follows)…
  • XP Practices diagram, from What is XP – “Simple Design” is a core element of XP. “[choosing the appropriate] Metaphor” is also important to keep your code simple. Not mentioned in the XP diagram, but implied is the concept of…
  • You Ain’t Gonna Need It (YAGNI) (from the original gangster C2 wiki) – don’t add anything to your code for “flexibility”, “modularity”, “just in case,” “something I will need later.” YOU, your SOURCE CODE REPOSITORY, and your PROGRAM REQUIREMENTS are the most flexible pieces. When you need something in your code later, add it later, at the moment you need it.