Discute-se muito por aí como se escrever um bom código, e grande parte das discussões é direcionada para a boa escrita de métodos. Sabe-se que um bom método deve ser pequeno, ter o mínimo de níveis de endentação, fazer apenas uma coisa e fazê-la bem, ter nomes significativos etc. Mas o que percebo é que pouco se fala sobre como definir melhor os parâmetros de um método.

Assim como questionar o uso de comentários no código, uma discussão sobre parâmetros de métodos pode se tornar também muito polêmica. Como gosto de compartilhar minhas opiniões e experiências (e por ser teimoso), além também de ouvir o que têm a opinar os outros profissionais, decidi escrever sobre este assunto. Então vamos lá!

Definindo parâmetros e métodos

Acredito que a definição da quantidade ideal de parâmetros seja um dos principais pontos para se conseguir um bom método. Uncle Bob classifica os métodos em seu livro “Código Limpo – Habilidades Práticas do Agile Software” como sendo nulo quando a quantidade de parâmetros é zero, Mônade quando é um, Díade quando são dois, Tríade quando são três e Políade quando a quantidade de parâmetros é superior a três.

As formas mais comuns de passar apenas um parâmetro para o método é quando fazemos uma pergunta sobre o parâmetro, ou simplesmente quando realizamos alguma transformação no parâmetro, retornando-o depois.

Um método com dois parâmetros já começa a ficar um pouco mais difícil de ser entendido, pois teremos que analisar melhor o que se deve passar, e consequentemente podemos errar a ordem da passagem dos parâmetros.

Uma Díade não é totalmente ruim, mas sempre que possível devem ser transformadas em Mônades. Como acho que os métodos Díades já são difíceis de entender, não preciso nem falar o que penso dos métodos Tríades. Com certeza se gastará bem mais tempo para analisar estes métodos e a probabilidade de um erro será maior.

Os métodos com apenas um parâmetro são comuns, além de serem bem úteis durante a codificação. Porém devemos tomar muito cuidado quando o parâmetro é um booleano.

Os parâmetros booleanos indicam explicitamente que o nosso método tem mais de uma responsabilidade, pois será feita uma coisa se o valor for verdadeiro e outra se for falso.

Simplificando a codificação

Já li métodos que a utilização de parâmetros booleanos pareceu simplificar mais a codificação. Como exemplo posso citar um método que oculta ou exibe um certo controle em um tela. Teoricamente isso se resolveria apenas com uma linha de código, mas fica bem claro que o seu método está tendo mais de uma responsabilidade ao mesmo tempo.

Um tipo de parâmetro que também deve ser evitado são os de saída. Um parâmetro quase sempre é interpretado como sendo de entrada, algo diferente disso pode gerar muita confusão e complicar o entendimento do método. O ideal é evitar o uso de parâmetros de saída!

Pode-se falar muito ainda sobre parâmetros, até mesmo porque acredito que há diversas opiniões sobre este assunto.

Bom mesmo seria se o nosso método não tivesse nenhum parâmetro, já que métodos assim são mais fáceis de ser entendidos e utilizados.

Muitos parâmetros podem causar confusão, sem falar também na complexidade que teremos durante os testes, pois o tempo para se testar as várias combinações com muitos parâmetros pode ser bem grande. Mas sei que nem sempre este cenário será possível e os parâmetros serão necessários.