Lombok - Você está usando errado!

Quem não curte manter o código mais limpo possível? Infelizmente o Java deixa um pouco a desejar nesse quesito, pelo fato de termos que explicitamente colocar construtores, getters, setters, toString, equals, hashcode, meu Deus!

Mas nem tudo está perdido meus jovens, existe uma lib bem comum na comunidade Java que nos ajuda muito a evitar esses códigos repetitivos e que geralmente são uma receita de bolo. E essa lib é o tão amado (ou odiado) Project Lombok. Esse projeto usa um processador de anotações pra gerar esses códigos em tempo de compilação.

A grande questão e polêmica do Lombok é que muitas vezes os desenvolvedores abusam e/ou fazem mal uso da ferramenta, fazendo com que o código acabe ficando mais complexo / difícil de manter.

Vou seguir com alguns casos comuns que já vivenciei no dia-a-dia e explicar o porquê eles são ruins.

Segue o exemplo:

@Data
@NoArgsConstructor
@AllArgsConstructor
public class Fulano {
  private String nome;
}

Por baixo dos panos é gerado um construtor padrão, um construtor com todos os parâmetros (no caso nome), getters, setters, etc.

Até aí nada muito absurdo, porém vamos a parte conceitual da coisa:

• Usamos construtor com argumentos para garantir que determinado estado do objeto seja garantido no momento da criação. Muito usado em objetos imutáveis (sem setters)
• Caso desejemos uma classe simples (POJO), é mais fácil dar um new no objeto e settar as propriedades via setter ao invés do construtor, deixando o código mais claro e limpo.

Outra anotação bem comum na comunidade Lombok é a @Builder. Tal anotação gera um Builder para criar objetos da classe anotada. Muitos a utilizam para deixar código mais claro no momento da construção de um objeto, mas isso vem com alguns problemas.

Seguindo o código abaixo:

@Builder
@Data
public class Fulano {
  private String nome;
  private int idade;
  private String cpf;
  private String rg;
}

Usando o builder acima, teríamos o seguinte código:

Fulano.builder()
  .nome("Meu nome")
  .idade(22)
  .cpf("123.234.123.88")
  .rg("11.123.456-9")
  .build()

O código por si só parece bem bonito e elegante, mas ele trás alguns problemas:

• Usamos o padrão Builder quando temos uma quantidade razoável de campos opcionais no objeto, sendo os obrigatórios settados na construção do Builder e o resto ficando a critério de quem está criando o objeto. Infelizmente o Lombok não da suporte a parâmetros na construção do Builder
• Não temos como garantir a consistência do objeto na sua criação. No caso acima, teríamos que checar em todos os pontos que criam uma instância de Fulano se a idade é positiva.
• Não sabemos quais campos do objeto são obrigatórios. No caso acima se esquecêssemos de adicionar o CPF por exemplo, poderíamos tomar uma NullPointerException em outro ponto no código. Esse erro é bem comum quando estamos criando objetos em classes de teste, onde quase sempre não é chamado todos os parâmetros do Builder.
• Se estamos usando o padrão Builder, então não faz muito sentido termos setters, correto?

Os problemas acima poderiam ser facilmente evitados se usarmos o compilador para nos ajudar. Criando construtores que garantem que todos os campos obrigatórios estão preenchidos e com consistência é a melhor forma de evitarmos futuros problemas / exceptions no uso do objeto.

Espero que os exemplos acima consigam dar uma visão melhor sobre alguns usos indevidos do Lombok. Claro que existem outros não citados, mas esses são os mais comuns que me deparo no dia-a-dia.

E fica a reflexão:
Não é só por que o código não aparece na IDE que ele não existe! Sempre pense e se pergunte se você escreveria o mesmo código que o Lombok gera. Se a resposta for não, provavelmente você precisa repensar melhor o como você usa essa ferramenta.