Method A (naked parameters) always has the advantages that
- it requires the method author to type less, since they don’t have to implement a Parameter Object,
- it requires the method caller to type less, since they don’t have to instantiate a Parameter Object
- it performs better, since no Parameter Object has to be constructed and garbage collected
- the reader can see what the individual parameters are from the method signature alone (but this is a double-edged sword; see below)
Method B (Parameter Object) has advantages when
- the parameters have domain meaning as a group, so the Parameter Object can be given a name that explains that meaning, saving the reader from having to read and understand each member of the group and how they relate
- the parameter list is used in more than one method, so using the Parameter Object in each reduces duplication
- the values in the parameter list are passed around among multiple methods as a group, which is easier when they can be passed as a single Parameter Object
- some combinations of values are invalid; the Parameter Object can prevent those combinations
- some values are optional, which can be provided by the Parameter Object instead of (depending on your language) default parameter values or overloaded methods
- there is more than one parameter of the same type, making value-swapping errors more likely (although a Parameter Object is not better in this case if it
has a constructor with the same parameter list as the method)
That the Parameter Object introduces a new dependency on which caller and callee depend is not much of a disadvantage, since it is a simple class with no dependencies of its own.
So, Parameter Object is
- almost never worthwhile for a single parameter, sometimes worthwhile for a two-parameter method (e.g. Point is usually better than x, y) and sometimes not, and increasingly helpful with three and more parameters
- increasingly helpful when more methods use the same parameter list