Reducing the Size of Parameter Lists
When writing a method, one of the first decisions is the signature of the method, that is, its name and the parameters that need to be supplied to the method. The name of a method is an important decision, but let us skip it for a while. Let us just consider the number of parameters in a method.
When we first think about the number of elements in a method, we usually get it right. That is because we think about the functionality of the method and what is most naturally thought of as the arguments for that method.
Reality Check
Things get complicated, however, when we get to write an implementation. Usually, we start getting tangled on the dependencies of the code that we want to write, and the easiest way to get out of the situation is adding more parameters to the method. This parameters inflation is bad in most of the cases. For exemple, Robert Martin in his book Clean Code, suggests that a method should have at most 3 parameters.
For example, suppose you want to write a method to return the add a value to the elements stored in a list. The natural way to do this would be
class MyClass {
// ...
public double addToEachElement(MyList l, double val){
// ...
}
}
Now, suppose however that to get hold of some information stored in the list you need an index. This data needs to be supplied in some way. The first reflex of someone that has been trained in structured programming is to add a parameter to the method:
public double addToEachElement(
MyList l, double val, int anIndex){ // ...
This will work in the short term, but there is a big problem with this kind of change: now there is a difference between what we intuitively think as what the method requires, and the reality that we need to supply an extra parameter just to satisfy the implementation.
A better way to handle this situation is to use OO design techniques to our advantage. One of the premisses of object oriented techniques is that objects should encapsulate information that is necessary for its implementation. We just figured out that anIndex is an implementation detail that has nothing to do with the addToEachElement method. The conclusion is that anIndex should be a member variable of MyClass, instead of a parameter.
Testing Methods
Another reason why methods should have fewer parameters has to do with testing of code. When creating tests, it is natural that we check combinations of values passed as parameters. However, a large number of parameters represents more combinations — which means that it becomes increasingly difficult to write tests that cover the important scenarios that will be faced by the method.
Reducing the number of parameters in a method
There are a number of options that we can follow to reduce the number of parameters in the methods we design:
- making the parameter a member variable: doing this allows the values to be codified in the state of the object. It is probably one of the first approaches you can try.
- grouping parameters into a new object: if you notice that certain parameters always go together, this suggests that they should be part of an object. Create a new class that represents the functionaity of these parameters, and pass the object instead.
- dividing the method: one of the reasons why a method has many parameters is that it may be doing too much. Try to divide the method into smaller ones. You should naturally see that only some parameters are used in a given part of the method, and therefore the newly created method for that part will not required that specific parameter.
Conclusion
Once you start to think about the principles of class and method design, the number of parameters per method in your implementations will reduce drastically.
Another advantage of thinking about the parameters passed to each method is that the code base will change for the better. What was once an amorphous set of method calls will gradually transform into something that has a meaning.
References
Robert Martin, Clean Code: A Handbook of Agile Software Craftsmanship, Prentice Hall, 2008
Kent Beck et al., Refactoring: Improving the Design of Existing Code (Addison-Wesley Object Technology Series).
Similar Posts:
About the Author
Carlos Oliveira holds a PhD in Systems Engineering and Optimization from University of Florida. He works as a software engineer, with more than 10 years of experience in developing high performance, commercial and scientific applications in C++, Java, and Objective-C. His most Recent Book is Practical C++ Financial Programming.
