Methods with many parameters are often sometimes unavoidable. In my own experience I often find this is the case for program entry points and complex mathematical procedures - where refactoring is either not possible, or would obscure the meaning of the method. Although there are no concrete limits for the number of parameters a method might have, it is patently undesirable to write/maintain/see methods with a large number of parameters.

An alternative is wrapping parameters into classes. This has some clear advantages, including:

  • Easier on the eye; nobody likes parameter fishing.
  • Easier maintenance; changing the parameters does not require modification to the method declaration.
  • Better typing; wrapping related parameters together into a single type can help clarify the meaning of the function.

However, there are several disadvantages to this approach:

  • Worse typing; coupling parameters that do not naturally fit together can be misleading.
  • Overloading becomes either impossible or messy.
  • Can impose unwanted foreign types on users.
  • Can lead to laziness.

For example: I've often seen Python code where the author repeatedly passes around objects generated by optparse (or argparse) whilst only using a small subset of the parameters in each method.

At the sake of brevity, here are the options:

my_method(Param1 a, Param2 b, Param3 c, ...., ParamInf zzz)
my_method(Params params)
my_method(Param1 a, Param2 b, Param3 c, SomeParams the_rest)
my_method(ParamSetA a, ParamSetB b, ...)

Whilst this is a somewhat subjective subject, I am interested to hear strategies for dealing with methods with large numbers of parameters. Real-life examples - especially those that have undergone code review - would be especially helpful.

  • I'm afraid that your question is rather opinion based and every answer will be valid. Rather ask for a concrete example where you get stuck with many parameters or rephrase your question.
    – valenterry
    Commented Jan 23, 2015 at 16:22
  • Your my_method examples are all named bad. The point here is, that putting multiple parameter into one or multiple parameter set or list is per se not a good idea. It only is a good idea if these parameters belong together. It should then not be a list but its own class (as you said). I also think your disadvantages are not valid, except the last maybe (which can't be helped anyways). I would like you to further explain the drawbacks, e.g. what you mean with "unwanted foreign types" or in which case overloading would become impossible or messy (while still beeing semantically correct).
    – valenterry
    Commented Jan 23, 2015 at 16:26

2 Answers 2


Methods with many parameters are often unavoidable.

Since when?

I mean it might be unavoidable to have a couple of methods like this in a non-trivial codebase, but the vast majority of your methods will have one or two parameters.

Having a boatload of parameters is a sign that: 1. Your function is doing too much. 2. Your boatload of separate parameters are really more cohesive than you thought.

How you solve the problem depends on which sign is applicable. If your function is doing too much, then splitting it up will naturally lead to fewer parameters - even if one orchestration function has too many. The more isolated code also makes it easier to see what's going on to simplify further.

If your parameters are more cohesive, then aggregating them (or at least some of them) into a useful bundle/class/structure is better since that would be used outside of just this one function.

But at least personally, I find parameter objects to be vile. If the parameters are cohesive, then they should've been in a class from the start. If you're making them into a class "to make that function prettier" then you're missing the point. Fix the problem, not the symptom.

  • By "parameter objects," do you mean parameter arrays? Parameter arrays can be extremely useful in some situations. Example: a command line that takes a variable number of parameters. Some Microsoft technologies routinely pass around a Context object (notably ASP.NET MVC and Entity Framework), which, at the end of the day, is really just a big bag of state. Commented Jan 23, 2015 at 16:35
  • @RobertHarvey - I meant where like you have int, double, string, string and toss them all into an object with no other use than being input to a function. C# style params arguments are fine - they're just syntactic sugar for collection initialization. Context objects are... less fine. Passing around arbitrary state (while occasionally the better of two evils) is the sort of thing that is regularly abused.
    – Telastyn
    Commented Jan 23, 2015 at 16:43
  • I too wish Microsoft had made a better choice... HttpContext is notoriously difficult to mock. If you're not referring to a DTO, then what does "If the parameters are cohesive, then they should've been in a class from the start" mean? Commented Jan 23, 2015 at 16:44
  • 1
    By "complex mathematical function" I imagine @FrankHileman is referring to calculations coming from real-world applications of math, like physics, statistics, economics, electronics, etc.
    – Doval
    Commented Jan 23, 2015 at 18:21
  • 1
    I once unit tested a 10-page mathematical function describing the ballistics of a bullet fired from a moving helicopter. It was decomposable. Commented Jan 23, 2015 at 23:01

The key factor here is how cohesive the parameters are.

If you have a group of parameters that are logically grouped and should belong to a class, then create a class for them. If they happen to occur together in parameter lists but are not logically grouped, keep them separate.

Keep this method as-is:

function getDistance(Point p1, Point p2) { ... }

This one might be better served with an object to group parameters:

function manufacture(Make make, Model model, Year year) { ... }

These parameters all work together to describe something:

class VehicleDescriptor {
  Make make;
  Model model;
  Year year;

function manufacture(VehicleDescriptor v) { ... }
  • I find myself on the same track, but if you take it a bit further - what do you call the class when there's another method that needs these three arguments, but also a fourth ("Colour", perhaps)? Do you create another class with the same three, plus the extra Colour property, and call it VehicleDescriptorWithColour? Especially if the two methods that need the class aren't necessarily related to or near each other. Commented Sep 23, 2016 at 9:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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