1

I know there are some questions about "Introduce parameter object", eg: Is "Introduce Parameter Object" actually a good pattern?, Should we avoid custom objects as parameters?, which means this form:

public void myMethod(int parameter1,int parameter2){
}

should be refactored as:

public class ObjectForMyMethod{
    public int parameter1;
    public int parameter2;
}
public void myMethod(ObjectForMyMethod objectForMyMethod){
}

which has some advantages, such as adding parameters without changing method signatures , and reduce the chance of passing list of data with same types in wrong order. However, in my experience, "Introduce parameter objects" are rare to see (ie: keep list of parameters instead of passing a single object).

Are all methods with more than one parameter instead of introducing parameter objects bad? Why don't we always "Introduce parameter objects"? Is "avoid introduce parameter objects" just a result of "lazy creating a new class"? If not, what is the good reasons to keep multiple parameters instead of introducing parameter objects?

wcminipgasker2023
  • 1,505
  • 1
    "should be refactored as" - em, no. Those question (as well as most other serious resources about that topic ) tell you one can refactor the first form into the second, not that you should. The top answer of your second reference speaks of a recommendation to introduce a parameter object for related parameters. – Doc Brown Oct 04 '23 at 19:44
  • I use parameter objects basically in three cases: I have a lot parameters to start with, I keep adding parameters or/and I would like to resolve target method based on type of parameter (in the last case not only I have parameter objects but also unique ones). – greenoldman Oct 07 '23 at 05:59

2 Answers2

7

I am running the risk of an opinionated answer here, but I would say that:

It depends if you can give the parameter object a meaningful name. For example if my parameter object is called Address and contains fields that are consistent with an Address is reasonable to use a parameter object.

In contrast if you name your parameter object MethodXYZParams it's probably a bad idea. The reason for this distinction is that when someone reads the method signature they should understand how the object is going to be used.

There is an anti-pattern that should be avoided, specifically that you have a huge parameter object that you pass down a call stack, where at each level methods extract a few random fields. If you do this there is no easy way to understand what parameters are important for each path through the call stack without examining each of the methods.

On the other hand if you parse a complex, but well designed model to a call tree (set of functions that call each other) and name the methods well processAddress() it should be easier to follow what is happening.

DavidT
  • 3,338
  • 3
    "Cohesion" is sometimes used to describe parameters that are strongly related, and might be worth mentioning. – JonasH Oct 04 '23 at 08:25
3

You should introduce parameter objects if and only if you can give it proper behavior.

This means that it should do something instead of just providing a grouping of some data elements. The method should then use this behavior instead of digging out the data from the object.

If you have lots of parameters, it is very likely, that you are missing an abstraction. It is unlikely that many parameters influence your method in unique ways, more likely a bunch of "data" is handled exactly the same way, like passing on, converting to something, persisting, etc. So extract that behavior into its own object.

Robert Bräutigam
  • 11,772