Object Calisthenics

Guidelines to writing clean better OO code

Google says calisthenics means “gymnastic exercises to achieve bodily fitness and grace of movement.” And the object is something we should already know as a developer. As you already figured out, this calisthenics are gonna help us write precise objects & classes that are easy to read and understand.

Object Calisthenics is a set of nine principles that were introduced by Jeff Bay in the book ThoughtWorks Anthology. Jeff Bay refers to his principles as “rules of thumb” and as guidelines to write well-designed Object-Oriented (OO) applications that focus on the important qualities of an application:

• cohesion
• loose coupling
• zero duplication
• encapsulation
• testability
• readability
• focus

Most of us might not even be completely aware of the concepts while learning to program. But as we continue our journey as a developer these all matter a lot in writing simple, straightforward maintainable applications.

The art of developing applications does not lie in the ability to solve complex problems but in the skill to write simple and clean applications that are reusable.

I know it’s really difficult for beginners to adapt to the mindset of OO-based development when coming from Procedural programming background. But only later do we realize how scalable and reusable our solutions are.

And with that being said, let’s explore the “rules of thumb” that allow you to make better decisions while trying to write better OO applications.

The nine principles as stated by Jeff Bay are:

1. Use only one level of indentation per method.
2. Don’t use the else keyword.
3. Wrap all primitives and strings.
4. Use first-class collections.
5. Use only one dot per line.
6. Don’t abbreviate.
7. Keep all entities small.
8. Don’t use any classes with more than two instance variables.
9. Don’t use any getters/setters/properties.

I’ll discuss the first two principles in detail in this article. And we’ll see the remaining in the next couple of articles.

1) Use only one level of indentation per method

The first and foremost thing that Jeff Bay tells us, is a very important principle related to the readability of code. I’m sure you would have come across some really ugly code that has a lot of if/else statements and for loops nested inside each other leading to a staircase inside the code.

Wrapping your head around such an application definitely takes time. And even if you understand such a code, you easily forget it before the next time you see it again. And as Jeff Bay states, it becomes really hard to figure out the reusability of a function with 5 responsibilities and 100 lines of nested loops and conditional statements.

I know this is a very trivial example and does not make any sense to have, but the intention here is to understand the principle well.

So, a simple fix suggested here is to extract the indented code into separate methods until you’re sure your method does only one thing. When you have multiple methods that do only one thing inside a class that has only one responsibility it becomes very easy to reuse it in other places.

And now the Single Responsibility Principle also comes into the picture.

2) Don’t use the else keyword

When someone says not to use the else keyword, you may think they’re crazy enough to say such a thing when you’re using it so often in your day-to-day development. But guess what? You become crazy after understanding how simple and readable the code becomes when you try to avoid the else as much as possible.

(I feel it would make much more sense had it named ‘avoid the else keyword’)

It is so common we have the urge to use if/else so often in our code, that we don't even realize how much it affects the readability and reusability for someone else. When there are better solutions to it, you should first understand why it is so bad to use one.

The moment you start writing if/else conditionals you easily get the urge to write another else on top of it when a new case arrives but new requirements always keep flowing in. And ‘else’ adds additional execution flows to the program. Then it leads to code duplication.

One important quality of a well-written OO program is zero or very little duplication. We should strive the most to achieve it. And that’s how we evolve to a mindset of OO thinking.

There are multiple solutions to this: Using an early return, using a switch case for multiple if/else conditions, ternary operators, or using a dictionary/hashmap to pick the right option for a key.

We can use a default value also and modify it only for certain scenarios and return it.

You can also make use of polymorphism to handle in a more OO way.

There are also design patterns like Strategy pattern (which I have used here), State pattern, and Null object pattern which are behavior-based patterns that greatly help to eliminate the use of the else keyword. Following design, patterns help us to create reusable, simple applications.

Have you ever known there are many ways to write better code instead of an else? And since you know now, try to make a better decision the next time you’re about to write an if/else block in your code.

I hope you found this article useful and understood how following some simple principles can lead to better-designed OO applications!

Feel free to share your valuable comments/feedback! Thank you for reading this!

Let’s make coding fun together! Follow for more content alike!

Join FAUN: Website 💻|Podcast 🎙️|Twitter 🐦|Facebook 👥|Instagram 📷|Facebook Group 🗣️|Linkedin Group 💬| Slack 📱|Cloud Native News 📰|More.

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author 👇