"Muitos parâmetros" é um problema visual ou lógico?

de acordo com Existem diretrizes sobre quantos parâmetros uma função deve aceitar? , um método não deve ter muitos parâmetros. No entanto, algumas respostas sugerem que esse problema pode ser resolvido pelo padrão do construtor:

Builder b=new Builder();
b.setParm1("a");
b.setParm2("b");
.
.
.
Obj obj=b.createObj();

ou encapsular parâmetros em um único objeto.

ObjectParam op=new ObjectParam();
op.param1="a";
op.param2="b";
.
.
.
obj.f(op);

Mas duvido que isso resolva o problema, porque acho que os métodos apenas alinham os parâmetros da melhor maneira (ou seja: de horizontal para vertical), mas isso não muda a natureza de que as tarefas dependem de muitos parâmetros. E se eu quiser que a cadeia de parâmetros tenha uma aparência melhor, posso usar uma nova linha para cada parâmetro como ele:

https://softwareengineering.stackexchange.com/a/331680/248528

então minha pergunta é: "muitos parâmetros" é um problema visual (difícil de ler uma longa linha de código) ou um problema lógico (a natureza da tarefa depende de muitos parâmetros e precisa ser quebrada)? Se se trata mais de um problema visual, uma nova linha para cada parâmetro resolve o problema?

É antes de tudo um problema lógico (que também costuma vir com problemas visuais). A solução errada para isso é tentar apenas melhorar o problema visual

encapsular parâmetros em um único objeto [...] apenas alinhar os parâmetros da melhor maneira (ou seja: de horizontal para vertical)

Encapsular parâmetros em um objeto não significa colocar cinco parâmetros em um contêiner arbitrário com algum nome sem sentido, como ObjectParam. Em vez disso, encapsular um grupo de parâmetros em um objeto deve criar uma nova abstração (ou reutilizar uma existente). Gostar

• encapsular três parâmetros "X, Y, Z" em uma posição "parâmetro do tipo Point3Dou

• encapsular parâmetros "startDate, endDate" em um objeto DateIntervalou

• encapsular parâmetros documentTitle, documentText, authorem um objeto Documentagrupando esses parâmetros

Se o método em jogo tiver muitos parâmetros não relacionados, você não poderá criar um bom nome de agrupamento, provavelmente terá muitos parâmetros e muitas responsabilidades.

Um método que utiliza muitos parâmetros é, essencialmente, um passo na direção oposta à da convenção sobre a configuração , que se concentra na simplificação de tais chamadas sem perder a capacidade de alterar valores conforme necessário através do uso de padrões sensíveis .

Em outras palavras, você claramente não quer perder flexibilidade, mas quase certamente não precisa que todos os parâmetros sejam passados ​​dinamicamente. Muitos parâmetros provavelmente serão fixos / estáticos. Tome um programa zip como exemplo. Sim, talvez você queira alterar o algoritmo de compactação, o nível de compactação, o número de núcleos da CPU a serem dedicados à tarefa, etc. O ponto é que ninguém deseja especificar todos esses parâmetros todas as vezes que você precisar criar um arquivo zip, reduzindo efetivamente uma chamada, fornecendo o essencial (por exemplo, nome do arquivo zip de destino, arquivos a serem adicionados ao arquivo zip).

Os motivos pelos quais você usaria a abordagem de convenção sobre configuração são os mesmos motivos pelos quais você não deve ter métodos que exijam muitos parâmetros. Em suma, a simplicidade é boa.