Object Calisthenics

Hi Dev, have you heard about Object Calisthenics before?

Object Calisthenics is a set of nine coding rules introduced by Jeff Bay in The ThoughtWorks Anthology. The term combines "Object", referring to object-oriented programming (OOP), and "Calisthenics", which means structured exercises — in this case, applied to code. These rules are meant to help developers internalize good OOP principles by practicing them at the micro level, directly in their day-to-day coding.

You’re not expected to follow every rule 100% of the time. Instead, the idea is to use them as a guide — a structured constraint — to help shift your coding habits and improve the design of your software. As you apply these rules consistently, you’ll begin to see the benefits: better encapsulation, cleaner abstractions, and more testable, readable, and maintainable code.

Seven of the nine rules focus directly on strengthening encapsulation — one of the core principles of OOP. Another encourages replacing conditionals with polymorphism. The final rule helps improve naming clarity by avoiding cryptic abbreviations. Together, they push developers to write code that is free from duplication and easier to reason about.

At first, following these rules may feel uncomfortable or even counterproductive. But that friction is exactly the point — it forces you to break old habits and rethink how your objects interact. Over time, these small design constraints train you to write code that is simpler, more focused, and easier to evolve.

In this article, we’ll go over the general idea, and in the next ones, we’ll dive deeper into each rule.

1. Only One Level of Indentation per Method

Keep your methods flat. Avoid nested conditionals and loops. Break logic into smaller methods to maintain clarity and single responsibility. Learn more.

2. Don’t Use the “else” Keyword

Instead of using else, return early or use polymorphism to simplify control flow. This reduces branching and makes code easier to follow.

3. Wrap All Primitives and Strings

Avoid using raw types like int or str directly. Create small, meaningful value objects that encapsulate behavior and validation.

4. First-Class Collections

A class that holds a collection should only hold that collection. No other fields. This helps centralize collection-related behavior and improves cohesion.

5. One Dot per Line

Avoid chaining calls like a.get_b().get_c().do_something(). It breaks encapsulation. Tell objects what to do instead of digging into their internals.

6. Don’t Abbreviate

Use full, meaningful names for classes, methods, and variables. Abbreviations hide intent and often signal poor design or misplaced responsibility.

7. Keep All Entities Small

Classes should be short (e.g., under 50 lines), and packages small (e.g., under 10 files). Smaller units are easier to understand, test, and refactor.

8. No Classes with More Than Two Instance Variables

Limit each class to two fields max. This forces high cohesion and helps you break logic into smaller, focused objects with clear responsibilities.

9. No Getters or Setters

Expose behavior, not data. Don’t let external code manipulate internal state. Objects should do things, not just hold and expose data.

Final Thoughts

Object Calisthenics isn’t about blindly following rules — it’s about challenging the way we write object-oriented code and making small, intentional design decisions that add up over time. These nine principles serve as a compass to guide us toward cleaner, more expressive, and maintainable software.

In the upcoming articles, we’ll take a deep dive into each rule. We’ll look at real-world Python examples, explore the practical benefits of applying them, and also be honest about the trade-offs involved. Whether you're working on a personal project or a large-scale system, applying even a few of these rules can transform the way you approach software design.

Stay tuned — the journey into elegant object-oriented code is just beginning.