Via Raganwald, I saw this post by Andrew Birnstock: Perfecting OO’s Small Classes and Short Methods. The post is a summary of an essay by Jeff Bay called Object Calisthenics, from the new Pragmatic Programmers book The ThoughtWorks Anthology.

“Object Calisthenics” is supposedly an exercise to get you to write better object-oriented code. Reading through the suggestions, I couldn’t decide if the article was serious or not. From Andrew’s summary:

Use only one level of indentation per method. If you need more than one level, you need to create a second method and call it from the first. This is one of the most important constraints in the exercise. Don’t use the ‘else’ keyword. Test for a condition with an if-statement and exit the routine if it’s not met. This prevents if-else chaining; and every routine does just one thing. You’re getting the idea. Wrap all primitives and strings. This directly addresses “primitive obsession.” If you want to use an integer, you first have to create a class (even an inner class) to identify it’s true role. So zip codes are an object not an integer, for example. This makes for far clearer and more testable code.

From what I can tell, this really is serious. These are supposed to be the object-oriented equivalent of chin-ups, designed to whip you into shape to write better OO code.

This strikes me as so bogus, I can’t even begin to describe it.

I’m not against OO: I’m a huge fan of Smalltalk, and I cut my programming teeth at one of the oldest object-oriented development shops. In fact, I keep thinking of something that Steve Northover used to say to me when I was on my first work term at OTI:

“That which obscures my code is bad.”

If you’ve ever seen a large body of code that adheres to The One True OO Style TM — like say, Smalltalk class libraries — you’ll understand that almost every step you take towards “true OO” is just another way of obscuring the meaning of your code. If you break your code up into 10 different methods, then that’s 10 different places I have to look to figure out what is going on. You’re just writing spaghetti code by a different name. If you’re building a very large library, then maybe, just maybe, the additional flexibility is worth it.

I think Paul Graham sums it up best in his essay Why Arc Isn’t Especially Object-Oriented: