Sometimes (rarely), it seems that creating a function that takes a decent amount of parameters is the best route.
O uso de vários parâmetros geralmente é um indicador claro de que você viola o SRP nesse método. É improvável que um método que precise de muitos parâmetros faça apenas uma coisa. Excpetion 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 múltiplos parâmetros como o diabo evita a água benta. Quanto mais parâmetros você usar dentro de um método, maior a chance de que o método seja (muito) complexo; mais complexidade significa: mais difícil de manter e menos desejável.
However, when I do, I feel like I'm often choosing the ordering of the parameters at random. I usually go by "order of importance", with the most important parameter first.
No priniple você está escolhendo aleatoriamente . É claro que você pode pensar que o parâmetro A é mais relevante que o parâmetro B ; mas isso pode não ser o caso para os usuários de sua API, que pensam que B é o parâmetro mais relevante. Então, mesmo se você estivesse atento ao escolher o pedido - para outros, poderia parecer aleatório .
Is there a better way to do this? Is there a "best practice" way of ordering parameters that enhances clarity?
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 escolher um idioma com parâmetros nomeados .
Isso é um agradável açúcar sintático que permite soltar o significado da ordem dos parâmetros: fn(name:"John Doe", age:36)
Nem toda linguagem permite tais sutilezas. Então o que então?
c) Você poderia usar um Dicionário / Hashmap / Matriz Associativa como parâmetro:
por exemplo. O Javascript permitiria o seguinte: fn({"name":"John Doe", age:36})
que não está longe de (b).
d) Claro, se você trabalha com uma linguagem estaticamente tipada como Java. você poderia usar um Hashmap , mas perderia as informações do tipo (por exemplo, ao trabalhar com HashMap<String, Object>
) quando os parâmetros tiverem tipos diferentes (e precisarem transmitir).
A próxima etapa lógica seria passar um Object
(se você estiver usando Java) com propriedades apropriadas ou algo mais leve como uma struct (se você escrever, por exemplo, C # ou C / C ++) .
Regra geral:
1) Melhor caso - seu método precisa do parâmetro no em tudo
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