Dealing with multiple input parameters using wrapper class

Question

As a sort of continuation of this, I have the following newbie question:

What difference is there in building a wrapper class that expects lots of inputs parameters and inputting those parameters directly into the final constructor?

Don't get me wrong, I think the multiple input parameter thing is pretty ugly, and I'm trying to get around it since just like the poster of that question, I need to deal with a Calculator-like class that requires a lot of parameters. But what I don't understand is what would a wrapper class for input parameters solve, since I also need to build the input class--and that's just as ugly as the other alternative.

To summarize, I don't think this:

MyClass::MyClass(int param1, int param2, int param3... int paramN)
{
    this->param1 = param1;
    this->param2 = param2;
    this->param3 = param3;
    ...
    this->paramN = paramN;
}

...is much different from this:

Result MyClass::myInterface(MyInputClass input)
{
    //perform calculations
}

MyInputClass::MyInputClass(int param1, int param2, int param3... int paramN)
{
    this->param1 = param1;
    this->param2 = param2;
    this->param3 = param3;
    ...
    this->paramN = paramN;
}

And, of course, I am trying to avoid setters as much as possible.

Am I missing something here? I'd love to have some insight on this, since I'm still a rather newbie programmer.

Answer 1

The biggest benefits are:

• Insulation from changes. You can add new properties to the parameter class and not have to change the class that uses it or any of its callers.

• Code reduction when you're chaining methods. If MyClass needs to pass its parameters around, MyInputClass eliminates a bunch of code.

Answer 2

Here is some of the reasons, one would like to use a parameter class:

• Reusability: You can save the parameters in a variable and reuse them, maybe in another method.
• Separation of concerns: Parameter handling, say to verify which parameters are active, which are in their correct ranges, etc., is performed in the parameter class; your calculation method only knows how to calculate, so in the future you know where is each and no logic is mixed.
• You can add a new value and impact minimally in your calcultor method.
• Maybe your calculator method can be applied to two different set of parameters, say on an integer and on a double. It is more readable/mantainable/faster to write the calculation logic just once and change the parameter object.

Some classes do not need to initialize every single field at the constructor. Sometimes setters are the way to go.

Answer 3

All the other points are completely valid and sound. Here's a little reinforcement from some authoritative text:

Code Complete suggests that you limit the number of parameters of any routine to seven, as "seven is the magic number for people's comprehension." It then goes on to suggest that passing more than seven parameters increases coupling with the calling scope and that you should use a structured variable (ala MyInputClass) instead.