Técnicas para minimizar o número de argumentos de função

No Código Limpo, está escrito que "o número ideal de argumentos para uma função é zero". As razões pelas quais são explicadas e fazem sentido. O que eu estou procurando são técnicas para refatorar métodos com 4 ou mais argumentos para resolver esse problema.

Uma maneira é extrair os argumentos para uma nova classe, mas isso certamente levaria a uma explosão de classes? E é provável que essas classes acabem com nomes que violam algumas das regras de nomenclatura (terminando com "Dados" ou "Informações" etc.)?

Outra técnica é transformar as variáveis ​​usadas por várias funções em uma variável membro privada para evitar que elas sejam transmitidas, mas isso expande o escopo da variável, possivelmente de forma que seja aberta a funções que na verdade não precisam.

Apenas procurando maneiras de minimizar argumentos de função, tendo aceitado os motivos pelos quais é uma boa ideia fazê-lo.

A coisa mais importante a lembrar é que essas são diretrizes, não regras.

Há casos em que um método simplesmente deve receber um argumento. Pense no +método para números, por exemplo. Ou o addmétodo para uma coleção.

De fato, pode-se argumentar que o que significa adicionar dois números depende do contexto, por exemplo, em ℤ 3 + 3 == 6, mas em ℤ _{| 5} 3 + 3 == 2 , portanto, o operador de adição deve ser um método em um objeto de contexto que usa dois argumentos em vez de um método em números que leva um argumento.

Da mesma forma, um método para comparar dois objetos deve ser o método de um objeto usando o outro como argumento, ou um método do contexto, usando dois objetos como argumento, portanto, não faz sentido ter um método de comparação com menos de um argumento.

Dito isto, há algumas coisas que podem ser feitas para reduzir o número de argumentos para um método:

• Torne o método menor : Talvez, se o método precisar de tantos argumentos, esteja fazendo muito?
• Uma abstração ausente : se os argumentos estão intimamente correlacionados, talvez eles pertençam um ao outro e há uma abstração que está faltando? (Exemplo de livro de texto canônico: em vez de duas coordenadas, passe um Pointobjeto ou, em vez de passar nome de usuário e email, passe um IdCardobjeto.)
• Estado do objeto : se o argumento for necessário por vários métodos, talvez ele deva fazer parte do estado do objeto. Se for necessário apenas para alguns dos métodos, mas não para outros, talvez o objeto esteja fazendo muito e realmente deva ser dois objetos.

Uma maneira é extrair os argumentos para uma nova classe, mas isso certamente levaria a uma explosão de classes?

Se o seu modelo de domínio tiver muitos tipos diferentes de coisas, seu código terminará com muitos tipos diferentes de objetos. Não há nada de errado nisso.

E é provável que essas classes acabem com nomes que violam algumas das regras de nomenclatura (terminando com "Dados" ou "Informações" etc.)?

Se você não conseguir encontrar um nome adequado, talvez agrupe muitos argumentos ou poucos. Portanto, você possui apenas um fragmento de uma classe ou possui mais de uma classe.

Outra técnica é transformar as variáveis ​​usadas por várias funções em uma variável membro privada para evitar que elas sejam transmitidas, mas isso expande o escopo da variável, possivelmente de forma que seja aberta a funções que na verdade não precisam.

Se você possui um grupo de métodos que funcionam com os mesmos argumentos e outro grupo que não, talvez eles pertençam a classes diferentes.

Observe com que frequência eu usei a palavra "talvez"? É por isso que essas são diretrizes, não regras. Talvez o seu método com 4 parâmetros esteja perfeitamente correto!

Observe que zero argumentos não implica efeitos colaterais, porque seu objeto é um argumento implícito. Veja quantos métodos de aridade zero a lista imutável de Scala possui, por exemplo.

Uma técnica útil que chamo de técnica de "foco da lente". Quando você focaliza uma lente de câmera, é mais fácil ver o verdadeiro ponto de foco, se você o levar longe demais, depois recoloque-o no ponto correto. O mesmo acontece com a refatoração de software.

Especialmente se você estiver usando o controle de versão distribuído, é fácil experimentar as alterações de software, ver se você gosta da aparência delas e recuar se não gostar, mas por algum motivo as pessoas geralmente parecem relutantes em fazê-lo.

No contexto da sua pergunta atual, isso significa escrever as versões de zero ou um argumento, com várias funções de divisão primeiro, então é relativamente fácil ver quais funções precisam ser combinadas para facilitar a leitura.

Observe que o autor também é um grande defensor do desenvolvimento orientado a testes, que tende a produzir funções de baixa aridade no início porque você começa com seus casos de teste triviais.

Uma abordagem que simplesmente (e ingenuamente - ou devo dizer cegamente ) apenas visa reduzir o número de argumentos para funções provavelmente não está correta. Não há absolutamente nada de errado em funções com um grande número de argumentos. Se eles são exigidos pela lógica, bem, eles são necessários ... Uma longa lista de parâmetros não me preocupa, desde que seja formatada e comentada adequadamente para facilitar a leitura.

No caso de todos ou um subconjunto de argumentos pertencerem a uma entidade lógica única e geralmente serem distribuídos em grupos por todo o programa, talvez faça sentido agrupá-los em algum contêiner - normalmente uma estrutura ou outro objeto. Exemplos típicos podem ser algum tipo de mensagem ou tipo de dados de evento .

Você pode facilmente exagerar nessa abordagem - depois de descobrir que empacotar e descompactar material de e para esses contêineres de transporte gera mais sobrecarga do que melhora a legibilidade, você provavelmente foi longe demais.

OTOH, grandes listas de parâmetros podem ser um sinal de que seu programa pode não estar adequadamente estruturado - talvez a função que requer um número tão grande de parâmetros esteja apenas tentando fazer muito e deva ser dividida em várias funções menores. Prefiro começar aqui do que me preocupar com o número de parâmetros.

Não existe uma maneira mágica: você deve dominar o domínio do problema para descobrir a arquitetura correta. Essa é a única maneira de refatorar: dominar o domínio do problema. Mais de quatro parâmetros são apenas uma aposta certa de que sua arquitetura atual está com defeito e errada.

As únicas exceções são compiladores (metaprogramas) e simulações, onde o limite é teoricamente 8, mas provavelmente apenas 5.