Emulate Keyword And Default Parameters

A nice pattern to be used especially when designing highly reusable classes/functions, with lots of options. We try to achieve Economy Of Expression for the client context, as well as Information Hiding as much as possible. In particular by language features such as Keyword Parameter Passing (Lisp, PL/SQL,Ada'95, Objective Caml, most Unix utilities with regards to command line invocation) strongly supports these properties and we want to emulate this behavior in language without support for Keyword Parameter Passing, following the principle Program Intoa Language.

In language such as Java, C++, C#, a serious limitation is lack of Keyword Parameter Passing. This makes creating frameworks with Long Parameter List unlikely. Often times I've seen people avoid a design with Long Parameter List just because it is thought ugly in Java. C++ went only a quarter of the way towards a good language design solution and it has default values. But that is a half-baked horror!! We'll see why.

A Long Parameter List is typical of an operation provided by a highly reusable framework, that has a lot of options. For example a Xerces SAX Parser has a long list of boolean options: whether or not to validate, to warn of various warnings, to load external dtds, to continue after errors, etc. Most of these do have sensible defaults, so in a language with default parameters, a call to the parse operation is just a one liner, where the client can affect just the paramters he's interested in, something like:

Now following the idiomatic standard, if I were to design the Parser Utility class, I obviously could not do it. How about in C++? Well, in C++ it is even worse, because the designer can mistakenly create something like:

And courtesy of C++, if the client needs to alter the rightmost or last option, optionN, he needs to specify all the other options:

Now we have to copy (meaning duplicate) the default parameters from the source code of Class to the place of the call. That's what I call coupling indeed. And for example if the user was to use something like the copy command on the Unix command line from a C++ API (see Long Parameter List) he may become aware not only of the existence and position of all the other parameters, but also the client becomes aware of their default values. How about if the default values are not fixed but only chosen later depending of the mandatory input (for example, if the source directory resides on a network SAMBA file system, a lot of parameters do not even make sense). So C++ default parameters are clearly unsatisfactory in the general case.

Therefore: Emulate Keyword And Default Parameters :

From the general method:

refactor to a Method Object. The preference in Java is for an Inner Class named Method Name Operation, having a private constructor taking the mandatory params. The fields of the inner class should correspond to both optional and mandatory params.

Then for each optional param, put the default value in the initialization of the corresponding fields, for example what in another language might be:

in Java will reflect in the inner class:

For each optional parameter create a X(value) method in the inner class that allows the client context to set the value of the parameter:

Please note that return this is essential for the syntactic trick we need to support in the client code. Add to the MethodObject a prototypical method call() or execute():

Added sometime later. I was bothered by the violation of Economy Of Expression that is apparent in the client context where the invocation looks something like this: new Method Object(value1, value2).ValueX(x).ValueY(y).call() . Surely the last call is superfluous. Therefore to my surprise I invented Use The Undescore so that if the functional object is f, rather than writing.

Now we replace the original method in the Outer Class:

So in the end, we offer a more convenient call to the client. Instead of

the client can now write:

He need not set any optional parameters because they are already set to default values in the initializer of our method object. Thus he effectively has now Keyword Parameter Passing.

In the form above the pattern still preserves the positional form for mandatory parameters. This is because the general rule for good design of Long Parameter List is that only very few parameters should be mandatory (strictly the minimum required), and the rest (which may be a lot -- try a man find command in Unix) should have sensible default values or otherwise should be able to have empty values. Therefore if you have only a few mandatory params (2,3 and at a maximum 4), it is generally no problem for the client to pass params by position. It also easier and faster to type.

The pattern can easily be adapted to emulate Keyword Parameter Passing even for the mandatory params, but if you have only 2 or 3 mandatory params this is not warranted. It will be more mess and won't make the code any clearer. But if you have 4 or more mandatory params, that is a strong Code Smell: try to change at least some of them from mandatory to optional by providing sensible values. Have pity on the guy who calls you! If you still thik you have to have lots of mandatory params go ahead and make them "keyword enabled" (left as exercise for the reader).

Added bonus'. In languages with keyword params the user of the call has to remember the name of your formal keyword correctly (possibly including the case). But now in Java your users will be able to use the (in)famous Control Space and the modern Java IDE will present a list of the options to be set. Advantage, Java!

Example: transform the code from

to:

Now after the designer of the reusable code went through all this hoopla, the client has the satisfaction to Emulate Keyword And Default Parameters:

Compared to:

Parser Utility.parse is handler ~validating:
false ~loadExternalDTDs: false ~namespaces: false

The Java solution has the same readability and decoupling benefits of real Keyword Parameter Passing (actually if we get rid of Java setXXX convention and we put just validating(false) it looks almost identical.

Ok, that's basically it. -- Costin Cozianu

Would an accurate paraphrase of this be "turn optional method parameters into static public properties"?

Actually the aparatus behind it is not at all interesting per se, and I wouldn't want to formulate a profound design pattern from here (like identifying new objects trying to pop out from the code) -- actually that's a drawback I think in many refacttoring patterns: that they make the details have some kind of importance as elements of OO design.

The bottom line is to faithfully emulate the syntax for the call in a language with keywords and optional parameters. That's why for example I prefer to have an inner class and not an Argument Object so that the call can be

and not

I hold that the firts form has an obvious Economy Of Expression advantage over the second form.

The first line communicates to the reader that it is a simple method call, and I don't want the caller to spend several lines of code trying to make a call, like in the XML parsing example posted on Keyword Parameter Passing. The second thing that is very important is to communicate are the names that are attached to the values, cause I had the pleasure to see APIs looking like this:

Under the Introduce Argument Object, I still see a lot of code out there written like:

/*-3-*/

And in fewer cases developer apply the return this trick, so you see a better form of Introduce Parameter Object:

/*-4-*/

Which is more esthetically pleasing. But if we hold that the best Economy Of Expression is done via Keyword Parameter Passing, then the form -1- is still closer to the ideal form: no superfluous "new Argument Type" sidetracks the reader from the intention of the expression, which is simply a function call wi8th keyword and optional parameter. Therefore in my view this is a better form of expression than that obtained with Introduce Parameter Object. --Costin

Another important decision is that the name of the auxiliary class is hidden. Actually that's a recurring pattern in my designs, whenever a class is just an auxiliary to a principal class, like it is in this case - it merely serves for synctactic trick, I want it hidden in the namespace of the main class. This way, when somebody looks at the package view in an IDE, or just at the list of java files in the directory, he only sees the important classes and not the insignifiant details.

Another approach is a "string" parameter that is parsed into local values. One basically creates an API to parse it and put it into a local associative array:

This can get fancier. For example, an alternative or extra for the 4th line:

A simpler approach is to put parentheses around Boolean-like flags:

This approach works reasonably well if there are a lot of on-off type of switches. It is also relatively easy and fast to parse, even in SQL expressions. I tried using commas, but they didn't work as well and in not as many languages. Often I find that only about 1 in 5 new parameters need to be anything other than on-off flags. Thus, the need to introduce a former parameter can be cut into about 1/5.

Another option is to use simple letters. However, these have obvious problems in the self-documenting department.

--top

Originally, the string parameter approach was described on another page and moved here. On the same page, for contrast, the following OO approach was described below. Although the Method Object approach is described above, the following is intended to complement the string parameter approach. And, from the admittedly biased position of being the author, I feel it is a clearer example than the one above. If it isn't, please feel free to delete it. Delete When Cooked

A parameter class is created, as follows:

Then you can use it like this:

Assume you have the following procedure or method with a Parms parameter.

You can invoke it like this:

If all you need are the defaults, it becomes this...

...or maybe even this, assuming appropriate logic in myFunct:

Note the use of 'return this' in the relevant methods so that their invocations can be chained, as shown above.

This approach is relatively faster than the string method described above and the syntax is checked at compile-time -- at the expense of a bit more code. It also supports more than just boolean parameters, though obviously the string-based technique can be extended to parse anything you like. In the absence of an object-oriented language, similar mechanisms can be built using C structs (or some equivalent in whatever language you're using) and associated functions/procedures to manipulate them.

-- Dave Voorhis

If one is using a dynamic/lax typing language or style, that compile-time checking is not an issue. Further, the string approach(es) allows one to store or use parameters to and from a database if necessary (it is poor normalization, but many-to-many tables can be overkill sometimes). It is also shorter, prints easily when debugging, and works in just about any language. But, to each their own.

It's only shorter if you entirely discount the string parser; the string method exhibits poorer performance; and compile-time checking is often desirable. As for printing easily when debugging, simply implement a toString() method in the Parms class.

Should dynamic strings be a desirable means of setting parameters (as from a database, though I'm not sure how that turns into poor normalization or what it has to do with many-to-many relationships), an appropriate parseParams(...) method can be implemented in or inherited into the Parms class. -- Dave Voorhis

I'm shocked that nobody has brought up taglists. These were used to very good effect in AmigaOS, for example, to replace long argument lists. I'm also aware of at least one X11 widget library which did something similar. I'm not sure which came first; probably the latter, but the technique applies generally. However, it requires varargs support to implement well.

QNX uses a somewhat related mechanism. You have a parameter block PB, and a set of flags indicating which fields of the PB you'd like to affect. For example:

This way, you have a finite list of parameters, while still having the flexibility of optionally setting only those parameters you'd like. --Samuel Falvo

See also Argument Object or Introduce Parameter Object from Martin Fowler's Refactoring Improving The Design Of Existing Code.

Category Refactoring, Category Language Feature

See original on c2.com