Question

This may be a JavaScript question, but in Node.js, I commonly see modules or methods take an “options” object as their argument. For an example, of what I’m talking about, please look at the below http.request() method taken from Node.js API docs.

var options = {
  hostname: 'www.google.com',
  port: 80,
  path: '/upload',
  method: 'POST'
};

var req = http.request(options, function(res) {
  console.log('STATUS: ' + res.statusCode);
  console.log('HEADERS: ' + JSON.stringify(res.headers));
  res.setEncoding('utf8');
  res.on('data', function (chunk) {
    console.log('BODY: ' + chunk);
  });
});

req.on('error', function(e) {
  console.log('problem with request: ' + e.message);
});

// write data to request body
req.write('data\n');
req.write('data\n');
req.end();

One of the problems I see in many programming languages is that arguments are passed without it being distinctive what value is suppose to correspond to what. Is this a technique used to make readability easier, or is there an underlying concept I’m missing? Can I reasonably use this same technique in other languages such as PHP? (with associative arrays instead of objects of course)

Answer 1

You certainly can use this technique in other languages. I can’t speak for any structural improvement it may have in JavaScript specifically, but to my knowledge the idea is one of reducing the number of input parameters.

As a stylistic concern (readability, supportability, all of that good intuitive stuff that software should have) the fundamental “rule” being followed here is that fewer method arguments are better than many. This is especially true if not all of the arguments are required.

Consider an example from a statically typed language, C#:

public Widget WidgetFactory(int widgetNumber, string widgetName, bool isActive, Widget parentWidget, List<Widget> childWidgets)
{
    // parentWidget may be null if there's no parent
    // childWidgets may be empty or null for no children
    // etc.
}

For a more complex object, this could get very ugly very fast. Imagine a ton of optional (nullable) parameters. (If you’ve worked with COM interop in .NET prior to 4.0, you don’t have to imagine it.) Imagine also if you had multiple functions which needed these parameters. Again, it gets ugly fast.

So a pattern to use would be to encapsulate all of the options into another object whose sole responsibility is to maintain those options:

public class WidgetCreationOptions
{
    public int WidgetNumber;
    public string WidgetName;
    // etc.
}

elsewhere…

public Widget WidgetFactory(WidgetCreationOptions options)
{
    // etc.
}

As the options get more complex and internally contain logic referencing each other, it makes more and more sense to abstract them into their own object. This is common OO practice for moving toward many small simple objects instead of fewer large ones.

Indeed, you’re absolutely correct in this statement:

One of the problems I see in many programming languages is that arguments are passed without it being distinctive what value is suppose to correspond to what.

There are a number of “code smells” when it comes to having many method arguments:

• Too many arguments.
• Boolean flags as arguments (indicating that the method being called does more than one thing)
• Nullable arguments (if you don’t need it, why require it?)

There are probably more that escape me at the moment. But, as you have determined, this is difficult to read:

someObject.SomeFunction(1, false, null, "this is a string", false);

Whereas this is much, much more clear:

var options = {
    widgetNumber: 1,
    isActive: false,
    widgetName: "this is a string"
};

// ... elsewhere ...

someObject.SomeFunction(options);