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.
From time to time I like to check on the evolution of dynamic languages, just to see what I am missing as a Java/C++ programmer. It is always an interesting travel, and each time I feel that the future will be really far away from the C-like languages that we currently use.
Last week, I spent a few hours taking a look at the progress of Smalltalk. In the Smalltalk camp there are several contenders for the best system, and it is not at all clear what the most productive system is. I have already tried VisualWorks, which is a cool environment. Although it is easy to use, there is the problem that it is closed source. This makes it practical to use VisualWorks only on commercial software, instead of writing open source software.
Even when doing commercial work, most companies will not invest money in an IDE for a language that they don’t know — which makes the barriers to use of a commercial Smalltalk is even bigger. Of course, there are several companies using Smalltalk, but there is always a specific reason for this — if you can’t find that reason you are out of luck.
Squeak
For this reason, I think an open source solution is the best bet for SmallTalk to succeed. And the best open source implementation of Smalltalk is of course Squeak. The only thing that I had against Squeak is the fact that they still insist in using a particular GUI that is completely different from any other UI in use nowadays. In fact, Squeak notion of UI is basically a copy of what a GUI might have looked like in 1980, when SmallTalk was being developed.
In particular, the idea of Squeak practically forcing users to rethink the way they use the mouse is absurd. In Morph, the Squeak GUI, every mouse action depends on a three-button mouse. To add some confusion, buttons are named by colors (instead or right-or-left button), so you need to remember what color is left or right. Many operations also require the middle button (represented by still another color), and if your don’t have a mouse with three buttons you probably need to simulate that one with control/shift combinations.
Imagine if I created a software that remapped the keyboard, and decided that each key would not produce the results that you are used to, but instead the combination of letters that I decided. Of course, you would dislike this program (to say the least). But this is exactly what Squeak requires from the user, who needs to relearn how the mouse works.
Squeak and WxWidgets
Hopefully, Squeak, being written in Smalltalk, is not totally bound to the decisions made by its creators. One thing that can be done is to use a separate UI, and disregard totally the mess of Morph. This was the route taken by the guys that ported WxWidgets to Squeak — resulting WxSqueak. WxSqueak is an extension to Squeak that implements the WxWidgets UI library. WxWidgets is a full featured GUI library that is supported on most platforms, such as Windows, Linux, and Mac OS.
With WxSqueak you can create SmallTalk programs that use the WxWidgets GUI, and therefore have a native look and feel. Thus, you can create a Windows program in Squeak, with native windows, toolbars, and menus. There is no need to program in another GUI such as morph, and make your users learn a new GUI paradigm just to execute your program.
WxWidgets is still in its early stages, but I found it very feature complete. Since it uses WxWidgets, which is a mature library, there is a large number of graphical controls that can be used from your program.
In the next weeks, I will be providing an example of a program written with Squeak and WxSqueak. I be also writing about some of the features of SmallTalk and Squeak that make it so useful for programmers in general. Keep reading, and I will add more details in future posts.
