Você Está Programando Java Errado (E Nem Percebe) — Descubra o Porquê
Se você trabalha com Java há algum tempo, provavelmente já se acostumou com certos padrões: métodos gigantescos, classes que fazem tudo e, vez ou outra, um código que só o você do passado entende. Mas e se eu te dissesse que você está programando Java errado — e nem percebeu?
Não, isso não é um ataque. É um convite.
Um convite para conhecer um conjunto de boas práticas que pode transformar completamente o jeito como você escreve código: o Object Calisthenics.
O que é Object Calisthenics?
Object Calisthenics (Calistenia de Objetos) é uma série de 9 regras simples propostas por Jeff Bay no livro “The ThoughtWorks Anthology”. Essas regras têm um objetivo claro: ajudar desenvolvedores a escrever código orientado a objetos de forma mais disciplinada, limpa e legível.
A ideia por trás dessas regras é similar à da calistenia física: treinar a musculatura — nesse caso, a mentalidade orientada a objetos.
Por que você está programando “errado”?
“Errado” aqui não significa que seu código não funcione. Provavelmente ele roda, passa nos testes e entrega valor. Mas será que:
- Ele é fácil de entender?
- Ele é fácil de manter?
- Ele é modular?
- Ele respeita princípios como SRP e OCP?
- Ele tem responsabilidades bem distribuídas?
Se você hesitou em responder “sim” para uma ou mais dessas perguntas, talvez Object Calisthenics seja o choque de realidade que você precisava.
Vamos explorar o que essas regras dizem — e por que elas vão abrir seus olhos.
As 9 Regras de Object Calisthenics
1. Um nível de indentação por método
Por que isso importa: múltiplos níveis de indentação indicam acoplamento e complexidade. Ao limitar para um único nível, você força a decomposição do código em métodos menores e mais coesos.
Como aplicar: se você tem um if dentro de um for, dentro de outro if, é hora de extrair métodos.
// Código confuso
public void process(List<Order> orders) {
for (Order order : orders) {
if (order.isValid()) {
// lógica complexa
}
}
}
// Código limpo com 1 nível de indentação
public void process(List<Order> orders) {
for (Order order : orders) {
processOrderIfValid(order);
}
}
2. Não use a palavra-chave else
Por que isso importa: o else frequentemente mascara uma falha no design. Geralmente, ele indica duas responsabilidades dentro de um mesmo método.
Como aplicar: use early returns para evitar else.
public void sendNotification(User user) {
if (!user.isActive()) return;
// apenas continua se o usuário estiver ativo
notificationService.send(user);
}
3. Encapsule todos os tipos primitivos e strings
Por que isso importa: tipos primitivos e strings são dados “nus”. Quando usados em excesso, tornam o código frágil e difícil de entender.
Como aplicar: use value objects para dar significado semântico aos seus dados.
// Evite
public void register(String name, String cpf, int age) { ... }
// Melhor
public void register(Name name, CPF cpf, Age age) { ... }
4. Primeira classe: coleções e objetos de dados não podem ser passados diretamente
Por que isso importa: passar listas ou mapas diretamente torna difícil garantir invariantes e encapsulamento.
Como aplicar: crie objetos que envolvam essas coleções e forneçam métodos claros de interação.
// Fraco
public void process(List<Product> products) { ... }
// Forte
public class ShoppingCart {
private final List<Product> products;
public void add(Product product) { ... }
public BigDecimal getTotal() { ... }
}
5. Evite usar getters/setters
Por que isso importa: getters e setters são uma forma sutil de expor o estado interno do objeto, violando encapsulamento.
Como aplicar: prefira métodos que expressam comportamentos.
// Em vez de
if (account.getBalance() > amount) {
account.setBalance(account.getBalance() - amount);
}
// Use
account.withdraw(amount);
6. Use apenas um ponto por linha
Por que isso importa: uma cadeia de chamadas (a.getB().getC().doSomething()) revela alto acoplamento e quebra da Lei de Demeter.
Como aplicar: delegue responsabilidades em vez de atravessar camadas de objetos.
// Errado
order.getCustomer().getAddress().getCity();
// Certo
order.getCustomerCity();
7. Não use objetos com mais de duas variáveis de instância
Por que isso importa: muitas variáveis em uma classe indicam acúmulo de responsabilidades. Isso tende a violar o princípio da responsabilidade única (SRP).
Como aplicar: quebre a classe em subcomponentes mais coesos.
// Exemplo ruim
class Invoice {
Client client;
List<Item> items;
BigDecimal total;
Date dueDate;
// etc...
}
// Melhor
class Invoice {
Client client;
InvoiceDetails details; // encapsula items, total, dueDate
}
8. Não use setters públicos
Por que isso importa: setters públicos permitem que qualquer parte do código altere o estado de um objeto — isso enfraquece a consistência.
Como aplicar: torne o objeto imutável ou controle mudanças com métodos explícitos e intencionais.
9. Todos os objetos devem ter comportamento
Por que isso importa: classes que são apenas estruturas de dados (DTOs) não têm lógica associada. Isso contradiz a ideia de orientação a objetos.
Como aplicar: mesmo um objeto simples pode ter métodos úteis que encapsulam lógica.
// Em vez de
public class Money {
BigDecimal value;
}
// Use
public class Money {
BigDecimal value;
public Money add(Money other) { ... }
public boolean isGreaterThan(Money other) { ... }
}
Mas isso não é exagero?
Você pode estar se perguntando: “preciso mesmo seguir tudo isso à risca?”
A resposta curta é: não obrigatoriamente.
Object Calisthenics não é uma religião. É um exercício de disciplina, e como todo exercício, seu objetivo é te tornar mais forte — no caso, mais capaz de escrever código legível, testável e com baixo acoplamento.
Ao aplicar essas regras com consciência, você:
- Enxerga melhor as responsabilidades no seu sistema
- Cria objetos mais coesos e reutilizáveis
- Reduz bugs causados por estados inconsistentes
- Facilita testes e refatorações
E como começar?
- Escolha uma ou duas regras por projeto novo.
- Aplique como um desafio pessoal (ou da equipe).
- Use em katas, pet projects ou revisões de código.
- Refatore uma classe antiga aplicando as regras e compare.
- Explique para alguém — isso força você a entender de verdade.
Conclusão: programar bem é mais que “fazer funcionar”
O Java é uma linguagem poderosa, mas também permissiva. Ele deixa você fazer tudo — até escrever código espaguete em orientação a objetos. Object Calisthenics entra como um freio e um guia. Ele te obriga a pensar, a modularizar, a refinar sua arquitetura, mesmo nos pequenos detalhes.
Se você quer evoluir como dev, precisa ir além de “rodou sem erro”.
Precisa de clareza, elegância e intenção no seu código. Object Calisthenics te ajuda a chegar lá.
Gostou do artigo?
👉 Compartilhe com seu time ou com aquele amigo que ainda escreve métodos com 200 linhas.