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.
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.
10
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) { ... }
1