Às vezes (raramente), parece que criar uma função que requer uma quantidade decente de parâmetros é a melhor rota.
O uso de vários parâmetros geralmente é um indicador claro de que você viola o SRP neste método. É improvável que um método que precise de muitos parâmetros faça apenas uma coisa. A excitação pode ser uma função matemática ou um método de configuração, onde de fato vários parâmetros são necessários. Eu evitaria vários parâmetros, pois o diabo evita a água benta. Quanto mais parâmetros você usa em um método, maior a chance de o método ser (também) complexo; quanto mais complexidade significa: mais difícil de manter e isso é menos desejável.
No entanto, quando o faço, sinto que estou frequentemente escolhendo a ordem dos parâmetros aleatoriamente. Eu costumo ir por "ordem de importância", com o parâmetro mais importante primeiro.
No princípio você está escolhendo aleatoriamente . Claro que você pode pensar que o parâmetro A é mais relevante que o parâmetro B ; mas pode não ser o caso dos usuários da sua API, que consideram B o parâmetro mais relevante. Portanto, mesmo se você estivesse atento na escolha do pedido - para outros, isso poderia parecer aleatório .
Existe uma maneira melhor de fazer isso? Existe uma maneira de "melhores práticas" de ordenar parâmetros que aprimore a clareza?
Existem várias maneiras de sair:
a) O caso trivial: Não use mais de um parâmetro.
b) Como você não especificou qual idioma você escolheu, existe a chance de você escolher um idioma com parâmetros nomeados . Este é um bom açúcar sintático, que permite diminuir a importância da ordem dos parâmetros:fn(name:"John Doe", age:36)
Nem todo idioma permite essas sutilezas. Então o que então?
c) Você pode usar um Dicionário / Hashmap / Matriz associativa como parâmetro: por exemplo, o Javascript permitiria o seguinte: o fn({"name":"John Doe", age:36})
que não está longe de (b).
d) Obviamente, se você trabalha com uma linguagem estaticamente tipada como Java. você poderia usar um Hashmap , mas perderia informações de tipo (por exemplo, ao trabalhar com HashMap<String, Object>
) quando os parâmetros tivessem tipos diferentes (e precisassem ser convertidos).
O próximo passo lógico seria passar um Object
(se você estiver usando Java) com propriedades apropriadas ou algo mais leve como uma estrutura (se você escrever, por exemplo, C # ou C / C ++).
Regra prática:
1) Melhor caso - seu método não precisa de nenhum parâmetro
2) Bom caso - seu método precisa de um parâmetro
3) Caso tolerável - seu método precisa de dois parâmetros
4) Todos os outros casos devem ser refatorados
MessageBox.Show
. Olhe para isso também.