Você sabe o que é Calistenia de Objetos?

Muitos de nós já tentaram aplicar todas as boas práticas de desenvolvimento ao mesmo tempo, certo!? Empolgados com os princípios do SOLID, padrões de projeto, arquitetura limpa, acreditamos que, se seguíssemos tudo desde o início, o sistema sairia perfeito.

Mas a realidade costuma ser diferente, o que geralmente encontramos é frustração, mais tempo gasto, menos entrega, e aquela sensação de que nada está bom o suficiente. Tentando seguir a cartilha ideal, acabamos deixando a prática de lado e nos rendendo ao ritmo acelerado do dia a dia.

Realidade x Teoria

Mesmo com planejamento, brainstorms e modelagem, a execução sempre traz mudanças, novas ideias surgem, requisitos evoluem, e restrições imprevistas aparecem. O que antes era uma arquitetura idealizada se transforma em algo vivo, adaptável, muitas vezes caótico.

Na pressa da primeira entrega, no MVP, é comum deixarmos de lado a aplicação rigorosa de boas práticas, e está tudo bem! - desde que exista consciência do porquê e vontade de evoluir depois.

Como muitos de nós aprendemos a lidar com isso?

A maioria dos devs passa por esse dilema, queremos escrever código limpo e sustentável, mas os prazos e a pressão puxam para o lado oposto. Com o tempo, muitos encontram um caminho do meio, entregar valor primeiro, mas cultivar o hábito de estudar, refatorar, experimentar. Seja em projetos paralelos, testes de conceito ou momentos de respiro entre as entregas, é nesses espaços que conseguimos amadurecer como profissionais. Foi nesse contexto que um conceito simples — mas poderoso — voltou à tona para alguns desenvolvedores, a Calistenia de Objetos.

O que é Calistenia de Objetos?

Inspirada na calistenia física, essa prática propõe uma série de exercícios disciplinados para melhorar o design orientado a objetos. Criada por Jeff Bay, a ideia não é seguir regras cegamente, mas sim refinar o pensamento orientado a objetos na prática, com pequenos desafios. Quero compartilhar com você as 9 regras, que prefiro adotar como sugestões:

1 Use apenas um nível de indentação por método

• Evite métodos longos e com múltiplos níveis de controle.
• Incentiva a extração de métodos e a delegação.

2 Não use a palavra-chave "else"

• Leva à escrita de código mais claro e com early return.
• Reduz a complexidade condicional.

3 Encapsule todos os tipos primitivos e strings

• Ao invés de usar int, string, etc. diretamente, encapsule em classes de valor (Value Objects).
• Melhora a semântica e evita valores "soltos".

4 Use apenas um ponto por linha

• user.getAddress().getStreet() é considerado ruim.
• Incentiva a Lei de Deméter (princípio do menor conhecimento).

5 Não abuse de objetos de estrutura (structs)

• Objetos devem ter comportamento, não apenas dados.
• Evita o estilo procedural disfarçado de OO.

6 Use primeiras classes (First-Class Collections)

• Evite passar List<Something> diretamente.
• Crie uma classe que encapsula a lista com comportamentos relevantes.

7 Não use getters/setters públicos

• Quebram o encapsulamento.
• Prefira métodos que exponham apenas comportamentos necessários.

8 Prefira composição a herança

• Torna o código mais flexível e desacoplado.
• Evita hierarquias rígidas.

9 Limite o tamanho das classes a no máximo 50 linhas

• Força responsabilidade única (SRP).
• Ajuda a manter o código modular.

Percebeu!? São diretrizes simples, mas que nos forçam a pensar melhor, a construir objetos mais coesos e a reduzir o acoplamento desde o início, sem precisar cair no over-engineering (de projetar um produto ou sistema de forma mais complexa do que o necessário).

E sobre o fanatismo?

Existe um risco real quando boas práticas viram dogmas: perdemos a flexibilidade, o senso de contexto e, às vezes, até a alegria de programar, por outro lado, quando essas práticas são encaradas como ferramentas para pensar melhor, tudo muda.

Boas práticas não são um fim. São um caminho, e como qualquer treinamento, não se faz tudo de uma vez. Vai-se praticando, incorporando aos poucos, ganhando força com o tempo.

Uma evolução contínua

Muitos desenvolvedores encontram equilíbrio quando param de tentar seguir tudo de uma vez, e passam a testar, adaptar e evoluir com intenção. Não se trata de buscar perfeição, mas de manter o olhar atento: o que posso melhorar hoje? O que posso tentar diferente? Como posso escrever código que sirva melhor ao time e ao negócio?

A Calistenia de Objetos é só uma das formas de desenvolver essa consciência.

E você?

Já passou por esse ciclo entre teoria e entrega? Já sentiu esse peso de ter que fazer tudo “certo”? ou aquele sentimento que seu código está muito “podre”?

Talvez esses sentimentos e/ou duvidas seja só você evoluindo, já pensou nisso?

Compartilhe suas ideias e experiências, isso nos ajuda a crescer, como comunidade, como profissionais.