Calisthenics - A Arte de Colar com Peso Corporal (Copy)

As 9 Sugestões do Object Calisthenics

No mundo do desenvolvimento, estamos acostumados a frameworks, bibliotecas, ORM, injeções de dependências, camadas e mais camadas de abstração. Mas e se propuséssemos um desafio diferente: codar "com o próprio peso", sem apoios externos, exigindo apenas da força da sua lógica e clareza estrutural? Assim como a calistenia corporal, nasce a Programacalisthenics.

Inspirado no termo "Object Calisthenics", criado por Jeff Bay, esse estilo de codificação busca exercitar os músculos lógicos do programador por meio de sugestões que provocam um design mais limpo, coeso e expressivo. Trata-se de um treino para sua mente, seu código e sua compreensão sobre orientação a objetos.

As 9 Sugestões do Object Calisthenics

"Chamamos de sugestões porque acreditamos que programar bem não é seguir regras rígidas, mas entender as consequências de cada escolha. E para isso, refletir é mais importante do que obedecer."

Apenas um nível de indentação por método
Evite estruturas aninhadas. Divida a lógica em pequenos métodos. Isso melhora a leitura e a manutenção.
Evite ELSE
Substitua por retornos antecipados (early return) ou por estratégias de polimorfismo. Reduz complexidade.
Encapsule todos os tipos primitivos e strings
Em vez de string nome, crie class Nome. Isso adiciona semântica e encapsula regras de negócio.
Coleções de primeira classe
Evite usar listas diretamente. Crie classes como Turma que encapsulam a List<Aluno> e adicionam comportamento.
Evite abreviações
Nomeie com clareza. calcTotal() pode ser calcularTotalPedido(). Custo é leve, benefício é duradouro.
Mantenha entidades pequenas
Classes e métodos devem ser curtos e com responsabilidades bem definidas.
Use poucas variáveis de instância por classe
Isso impõe foco na responsabilidade. Se precisar de muitas, talvez precise de outra classe.
Evite getters e setters
Em vez de expor dados, exponha comportamentos. Use pedido.finalizar() ao invés de pedido.setStatus("finalizado").

Apenas um ponto por linha
Respeite a ideia da Lei de Demeter: aluno.getEndereco().getRua() indica acoplamento excessivo. Prefira aluno.rua().

Encapsulamento real não permite que você veja como as coisas são organizadas internamente. Se você consegue escrever obj.A.B.C, o encapsulamento não existe — ele é apenas uma ilusão elegante. Se o mundo externo conhece a estrutura interna de um objeto, ele já está acoplado a ela.

Por que treinar assim?

Essas sugestões são como os exercícios básicos da calistenia: simples, mas exigentes. Forçam você a pensar em design, a desacoplar, a dar significado ao código. Mesmo que você não adote todas, experimentá-las como desafio prático abre sua mente para novas abordagens.

Código Nu, Mente Forte

Na filosofia do TheCodeNaked, essa abordagem casa perfeitamente: é o código com o peso do próprio corpo. Não há truques, não há muletas. Apenas você, sua linguagem, e a lógica que sustenta o sistema.

Quer se desafiar? Escolha um problema simples e reescreva utilizando todas essas sugestões. Depois compare com sua versão anterior. Talvez você descubra que está mais forte do que imagina.

Interfaces e o Fim da Lei de Demeter

Interfaces são comumente vistas como ferramentas de encapsulamento. Mas há uma contradição essencial nesse pensamento: para que uma interface funcione, ela precisa tornar métodos visíveis externamente. Isso significa que, mesmo que a implementação concreta deseje manter parte da lógica como privada, ela é obrigada a se expor.

A interface não encapsula — ela padroniza a exposição. Ela formaliza o acoplamento.

E mais: se todos que conhecem a interface têm acesso garantido aos seus métodos, então a Lei de Demeter perde sua razão de ser. Afinal:

"Com interface, não existe mais ‘amigo próximo’ — todo mundo vira vizinho de porta."

Interfaces podem ser úteis, claro, mas não se iluda: elas não ocultam, apenas deslocam o acoplamento para outro lugar.

TheCodeNaked: onde o código se mostra por completo.