Eu diria que continue do jeito que você fez antes. O número de parâmetros em seu exemplo não é muito, mas as alternativas são muito mais horríveis.
Mapa - Existe a questão da eficiência que você mencionou, mas o maior problema aqui são:
- Os chamadores não sabem o que enviar sem se referir a
outra coisa ... Você tem javadocs que afirmam exatamente quais chaves e
valores são usados? Se você fizer isso (o que é ótimo), ter muitos parâmetros também não será um problema.
- Torna-se muito difícil aceitar diferentes tipos de argumento. Você pode restringir os parâmetros de entrada a um único tipo ou usar Map <String, Object> e converter todos os valores. Ambas as opções são horríveis na maioria das vezes.
Objetos de invólucro - isso apenas move o problema, visto que você precisa preencher o objeto de invólucro em primeiro lugar - em vez de diretamente para o seu método, será para o construtor do objeto de parâmetro. Para determinar se mover o problema é apropriado ou não depende da reutilização do referido objeto. Por exemplo:
Não usaria: Seria usado apenas uma vez na primeira chamada, então muito código adicional para lidar com 1 linha ...?
{
AnObject h = obj.callMyMethod(a, b, c, d, e, f, g);
SomeObject i = obj2.callAnotherMethod(a, b, c, h);
FinalResult j = obj3.callAFinalMethod(c, e, f, h, i);
}
Pode usar: aqui, pode fazer um pouco mais. Primeiro, ele pode fatorar os parâmetros para 3 chamadas de método. ele também pode executar 2 outras linhas em si mesmo ... então se torna uma variável de estado em certo sentido ...
{
AnObject h = obj.callMyMethod(a, b, c, d, e, f, g);
e = h.resultOfSomeTransformation();
SomeObject i = obj2.callAnotherMethod(a, b, c, d, e, f, g);
f = i.somethingElse();
FinalResult j = obj3.callAFinalMethod(a, b, c, d, e, f, g, h, i);
}
- Padrão Builder - este é um anti-padrão na minha opinião. O mecanismo de tratamento de erros mais desejável é detectar antes, não depois; mas com o padrão do construtor, as chamadas com parâmetros obrigatórios ausentes (o programador não pensou em incluí-lo) são movidas do tempo de compilação para o tempo de execução. Claro, se o programador intencionalmente colocar null ou algo semelhante no slot, isso será o tempo de execução, mas ainda detectar alguns erros antes é uma vantagem muito maior do que atender aos programadores que se recusam a olhar os nomes dos parâmetros do método que estão chamando. Acho que é apropriado apenas ao lidar com um grande número de parâmetros opcionais e, mesmo assim, o benefício é marginal, na melhor das hipóteses. Sou totalmente contra o "padrão" do construtor.
Outra coisa que as pessoas esquecem de considerar é o papel do IDE em tudo isso. Quando os métodos têm parâmetros, os IDEs geram a maior parte do código para você e você tem as linhas vermelhas lembrando o que você precisa fornecer / definir. Ao usar a opção 3 ... você perde isso completamente. Agora cabe ao programador acertar, e não há pistas durante a codificação e o tempo de compilação ... o programador deve testá-lo para descobrir.
Além disso, as opções 2 e 3, se adotadas de forma ampla desnecessariamente, têm implicações negativas de longo prazo em termos de manutenção devido à grande quantidade de código duplicado que gera. Quanto mais código houver, mais há para manter, mais tempo e dinheiro é gasto para mantê-lo.