I was mind-blown the day I learned about these rules and made me a better programmer instantly

George Studenko

Follow

Jul 28 · 4 min read

I’m talking about Object Calisthenics, and if you have not heard about it, then you should definitely learn this!

During the years I had the opportunity to present this to many developers, and the reactions are always the same, first people think is a joke and they even say: “How am I supposed to write any code with these rules!”, but after trying it out most of them will agree that in fact, you can write cleaner code almost instantly if you apply the rules!

So what is it?

Jeff Bay, originally coined the term Object Calisthenics in The ThoughtWorks Anthology book as a group of exercises to Object-Oriented programming.

By applying object calisthenics you can get code that is more:

• Readable
• Reusable
• Testable
• Maintainable

The idea is to use this as an exercise, although you should be able to apply most of the rules when programming, sometimes it won't be practical and you won't be able to do it, or it might be just very difficult to do so, in that case, use common sense and think of the trade-offs.

So start any code kata you like and follow strictly these rules, even though some might sound stupid, just do it:

1. Only one level of indentation per method.

This will make a method more readable as you will need to extract out pieces of code for example for loops or conditionals and put a meaningful name to those methods which are going to be called in this method.

Benefits

• Single responsibility
• Better naming
• Shorter methods
• Reusable methods

2. Don’t use the else keyword

The “else” keyword will add complexity to the code and create non linear flow (adding more use cases)

Ways to avoid using the else keyword

• Use default values
• Early return
• Extract code
• Use polymorphism
• State pattern
• Strategy pattern

Benefits

• Avoid code duplication
• Lower complexity
• Readability

3. Wrap primitive types

By wrapping primitive types into classes we can encapsulate the type and have control from a single place in case we need to refactor or change the primitive type, later on, it also helps to make it more readable by giving a hint of what exactly a method parameter is receiving.

Benefits

• Encapsulation
• Type hinting
• Attracts similar behavior

4. One dot per line

This applies the Demeter law: Only talk to your friends

So things like object.getProperty().getSubProperty().doSomething() is probably a really bad idea!, you just know too much of the implementation details.

Benefits

• Encapsulation
• Open/Close Principle

5. Do not abbreviate

If you are abbreviating the method may be doing more than it should (violating the single responsibility principle), so think again.

Ever found a weird abbreviated method name or variable that could mean 5 different things without having the right context?, then don’t be the one making these abbreviations!

Benefits

• Single Responsibility principle
• Avoid confusion
• Avoid code duplication

6. Keep classes small

• 15–20 lines per method
• 50 lines per class
• 10 classes per package

After all, if your class is specialized in a single thing, it will probably be small right?

Benefits

• Single Responsibility principle
• Smaller modules
• Coherent code

7. No more than 2 instance variables per class

A single class should handle only one state and two at most, so having more than 2 instance vars might be violating SRP.

This might sound like a hard one to do, I’m sure you had seen a class that takes in 18 inputs in the constructor right?

Well!, maybe you could group those into an object?, or maybe you might need to re-think if the design of that class is the best one, or if it is just doing too many things.

Benefits

• High cohesion
• Encapsulation
• Fewer dependencies

8. First class collections

This is similar to rule #3 but applied to collections.

Inside your class, you will still define a primitive collection type, but this way you could easily refactor as needed in the future and change the primitive collection type in a single place if needed.

Benefits

• Wrap primitive collections
• Behavior or related collections have a home
• Encapsulation

9. Do not use getters and setters

Don’t make decisions outside of the class, let the class do its job, follows the Tell don’t ask principle

Benefits

• Open/close principle

So there you have it!, the first time you try to apply these rules strictly, it might be really hard to do so and you might be tempted to not follow the rules, remember for the sake of the exercise, make sure to do it (no excuses!).

However feel free not to follow these rules strictly when developing on a daily basis, always think of the tradeoffs and decide what is best!

Did you find this article useful?

Share your comments and experience! let us know what works and what did not work for you.

Make sure to give this post some claps (50 or so is a good number!) if you enjoyed this post and want to see more.

And to keep up to date make sure to follow, until next time!

Are you looking for a mentor? get in touch!

You can find the links to my social networks links here: https://linktr.ee/gnstudenko