Is "too many parameters" a visual or a logical issue?

Question

according to Are there guidelines on how many parameters a function should accept?, a method should not have too many parameters. However, some answers suggest this issue can be solved by builder pattern:

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

or encapsulate parameters in a single object.

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

But I doubt if it solves the problem, because I think the methods about just align the parameters at better way (i.e.:from horizontally to vertically), but it doesn't change the nature that the tasks depend on too many parameters. And if I want the chain of parameters have better looking, I can use a new line for each parameter like it:

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

so my question is, is "too many parameters" a visual issue (hard to read a long single line of code), or a logical issue (the task nature depends on too much parameters and needs break down)? If it is more about a visual issue, does a new line for each parameter solves the issue?

Answer 1

It is first and foremost a logical issue (which often comes with visual issues, too). The wrong solution to this is by trying only to improve the visual problem by

encapsulate parameters in a single object [...] just align the parameters at better way (i.e.:from horizontally to vertically)

Encapsulating parameters in an object does not mean to put five parameters in an arbitrary container with some meaningless name like ObjectParam. Instead, encapsulating a group of parameters in an object should create a new abstraction (or reuse an existing one). Like

• encapsulating three parameters "X,Y,Z" in a parameter "position of type Point3D, or

• encapsulating parameters "startDate, endDate" in an object DateInterval or

• encapsulating parameters documentTitle, documentText, author in an object Document grouping these parameters together

If the method in stake has a lot of unrelated parameters you cannot come up with a good grouping name, then it has probably too many parameters and too many responsibilities.

Answer 2

A method taking many parameters is in essence, a step in the opposite direction from convention over configuration approach, which centers around simplifying such calls without losing the capacity to change values as necessary through the use of sensible defaults.

In other words, you clearly don't want to lose flexibility, but you almost surely do not need every single parameter to be passed dynamically. A good many parameters are likely going to be fixed/static. Take a zip program as an example. Yes, perhaps you may wish to change the compression algorithm, level of compression, number of CPU cores to dedicate to the task, .. whatever. The point is that nobody wants to specify all these parameters each and every time you need to create a zip file, effectively reducing a call by providing the bare essentials (i.e. destination zip file name, files to add to zip file).

The reasons you'd use convention over configuration approach is the same reasons why you shouldn't have methods requiring many parameters. In short, simplicity is good.