Um bate-papo sobre métodos – mas sem parâmetros!

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↳Clean code4 conteúdosMelhores práticas de segurança com o GitHub CopilotDevSecOps · dez 2025Estruturando Arquitetura API .Net Core 2.2Dev (Back & Front) · ago 2019Padronização no código e na equipeDev (Back & Front) · jun 2019Ver tudo em Dev (Back & Front) → – Habilidades Práticas do Agile↳Agile11 conteúdosO antiágil: quais as práticas que te afastam do AgileGestão Dev & TI · ago 2020Adoção de metodologias ágeis em TI pode fazer a diferença em um mundo de rápidas mudançasGestão Dev & TI · mai 2023Webinar HostGator mostra como usar Metodologias Ágeis para tirar um projeto do papelGestão Dev & TI · mai 2019Ver tudo em Gestão Dev & TI → 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.