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();
Obj obj=b.createObj();

or encapsulate parameters in a single object.

ObjectParam op=new ObjectParam();

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:


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?

  • 3
    IMO too many parameters is more of of a code smell for a logical issue. Too many parameters imply too many dependencies => the method is possibly doing too many things. Of course there are situations where too many parameters can be fine from a SRP standpoint (eg. you've opted to pass in a long list of parameters instead of using a list), but indicates other issues (wrong choice / absence of data structure) Mar 21 '18 at 6:26

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.

  • 7
    Poeple also try to fix the visual issue, by moving function parameters to class level, making it less cluttered, but less obvious, and with the same logical complexity. Or even worse, move the parameter to global state, because you don't want to pass it around. It happens... Mar 21 '18 at 10:43
  • 1
    @ChrisWohlert Yes, there are people believing that following lots of "rules" makes your code better - because they don't know what they are doing. Competent developers know when to better ignore the rules than create kludges just to follow the rule. Mar 21 '18 at 19:20
  • A parameter list, and a parameters "object", are nearly the same thing, in terms of mental load and possibly even syntax. This is a good answer. Mar 22 '18 at 21:46

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.