Quantos argumentos cabem em um construtor?

Recentemente me deparei com um código Java um tanto horripilante: algo como a cena que mais te impressionou no filme Anticristo de Lars von Trier.

Era a classe de um service que possuía mais de 42 argumentos no construtor. Em unidade de medida de gestantes, também conhecida por semana, isso seria o suficiente para dar à luz um bebê. E faço esse paralelo apenas para que você entenda a magnitude do problema.

Quando algo assim acontece, você fica olhando pro vazio refletindo, tal qual Wagner Moura em Narcos.

"There is a time to fight and there is a time to be clever" - Pablo Escobar

O problema

Depois de passar por um mau quarto de hora, você passa a buscar respostas na literatura. Robert C. Martin no livro Clean Code, por exemplo, apresenta uma opinião bem radical: três argumentos em uma função é o limite. Ele argumenta que as funções ideais possuem 0 argumentos. No nosso caso, número de argumentos em um construtor, eu discordo que devamos limitar a três, sejamos mais leves. Ao som de Angus & Julia Stone.

Particularmente procuro observar como limite a regra imposta pelo Sonar, sob a tag brain-overload. Ela estabelece 7 como o limite de argumentos em um construtor. Acima disso, o Sonar aponta como code smell. O racional por trás disso é que é muita coisa para manter na cabeça. Além disso, uma longa lista de parâmetros indica que uma nova estrutura deve ser criada para agrupar estes parâmetros ou que a função/classe está fazendo muito mais do que deveria.

Sobre o nosso problema, o caos primordial dos 42 argumentos, é algo que ocorre naturalmente em grandes projetos no decorrer do tempo quando não há uma análise constante e refatorações. A classe estava fazendo coisas demais. Ou seja, estávamos ferindo o Single-responsibility principle, que diz que todo módulo, classe ou função deve possuir responsabilidade apenas sobre uma parte da funcionalidade de um programa, e que deve encapsulá-la. Em orientação a objetos existe até um termo que define esse anti-pattern: god object.

Apropriando-me de uma expressão lusitana: com um god object em mãos estamos “feitos ao bife”. E uma vez em apuros, o que podemos fazer? É aí que entram algumas estratégias de refatoração.

A solução

Como discutimos anteriormente, uma classe com muitas responsabilidades é um problema. Para tratar disso, precisamos separá-la em classes menores, utilizando técnicas de refatoração. Por sorte temos um ótimo material do site Refactoring Guru:

• Extract Class: pode ser útil se parte do comportamento da classe gigante pode ser desmembrado em um componente separado;
• Extract Subclass: se você identificar que parte do comportamento da classe pode ser implementada de maneiras diferentes ou for usada apenas em casos raros, é uma boa estratégia;
• Extract Interface: caso seja necessário ter uma lista das operações e comportamentos disponíveis para o cliente utilizar.

---

Por enquanto é isso, obrigado por ler até aqui. Em um futuro artigo nós vamos realizar juntos a refatoração de um god object utilizando as técnicas de extrair classe, subclasse e interface.

Ah, caso você tenha passado por situação semelhante a dos 42 argumentos, conte pra mim nos comentários como foi e se você fez algo além de deitar no chão em posição fetal.