Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

JavaScript for C# developers: the Module Pattern (part 1)

DZone's Guide to

JavaScript for C# developers: the Module Pattern (part 1)

· Web Dev Zone
Free Resource

Add user login and MFA to your next project in minutes. Create a free Okta developer account, drop in one of our SDKs to your application and get back to building.

If you recall, JavaScript closures are an extremely powerful concept in the language. By using JavaScript’s rather peculiar scoping rules, closures are a way of creating private variables and functionality for an object. The module pattern builds upon this feature.

A quick recap on scope in JavaScript may be in order. Scope is the means by which programmers limit the visibility and the lifetime of their variables and parameters. Without scope, all variables would be global and visible everywhere. In C#, scope is introduced by braces: you can declare a new variable inside some code in braces — a block — and that variable would not be visible outside the block, and in fact would be destroyed once execution reaches the closing brace. These braces can be the braces surrounding the code in a method, or they can be the braces delineating a block for an if or a for statement, and so on. The essence of scope in C# is: declare a variable inside a block and it won't be visible outside the braces enclosing the block. (For full details about scope in C# you should read section 3.7 of The C# Programming Language (Fourth Edition) by Hejlsberg et al. There’s roughly eight pages of discussion on scope.)

In JavaScript, there is one basic rule: functions define scope. If you declare a variable in a function, it is visible anywhere inside that function, including inside any nested functions, even before it was declared. It is not visible outside the function. Since nested functions are also variables, they will also be visible anywhere in the enclosing function, even before they are declared. In essence, JavaScript hoists all variables to the top of the enclosing function so that they are declared before they are set with a value. This is like the lexical structure of Pascal with its var blocks, except that this hoisting occurs automatically in JavaScript.

Note that by nested functions, I mean functions nested in a lexical sense not in an execution sense. In other words, if function A calls function B, it doesn’t mean that B can suddenly ‘see’ the variables declared in A. For that to happen, B must be coded within the source code for A. It’s the lexical nesting that provides scope.

Let’s see this in code:

var outerFunc = function (paramOuter) {
  // Visible: paramOuter, varOuter
  //          nestedFunc1, nestedFunc2
  var varOuter = 42;

  var nestedFunc1 = function (paramNested1) {
    // Visible: paramOuter, varOuter
    //          nestedFunc1, nestedFunc2
    //          paramNested1, varNested1,
    //          nestedFunc1inner
    var varNested1 = false;

    var nestedFunc1inner = function () {
      // Visible: paramOuter, varOuter
      //          nestedFunc1, nestedFunc2
      //          paramNested1, varNested1,
      //          nestedFunc1inner, inner1
      var inner1 = "hello";

    };
  };

  var nestedFunc2 = function (paramNested2) {
    // Visible: paramOuter, varOuter
    //          nestedFunc1, nestedFunc2
    //          paramNested2, varNested2
    var varNested2 = false;

  };
};

It’s not exactly an example of some edifying code, but it gets the point across. If you look at the nestedFunc1inner function, you can see that all of the variables from the outer function are in scope as well as all the variables from the immediate parent function as well.

The nifty thing about these scoping rules is how well it plays along with closures. A closure encapsulates a function’s environment so that it can continue to exist as an object even after the function terminates. In C#, you see this most of all with lambda expressions and anonymous delegates, but with JavaScript you see it all over the place. jQuery is, in essence, one gigantic closure.

Let’s suppose we have to write a stopwatch object, which we’re going to use to time sections of our JavaScript code. The object should have a start() method that starts the stopwatch ticking, a stop() method to stop the watch (and which should also return the number of milliseconds elapsed). Without closures we’d probably write something like this:

var stopwatch = {
  startTime: -1,

  now: function () {
    return +new Date();
  },

  start: function () {
    this.startTime = this.now();
  },

  stop: function () {
    if (this.startTime === -1) {
      return 0;
    }
    var elapsedTime = this.now() - this.startTime;
    this.startTime = -1;
    return elapsedTime;
  }
};

Notice that I have a helper method called now() (that construction of +new Date() looks too weird in actual code – what does it do again?) as well as an internal field that records the start time of the stopwatch. Unfortunately although this object nicely encapsulated these two members, they are public, fully visible. We have not hidden them. A user of the stopwatch object could access them, change the variable, replace them, whatever. Also, I hate to say it, but all those required references to this doesn’t half obfuscate the code and make it long-winded.

Enter the module pattern. With the module pattern, we create an anonymous function and execute it automatically. The function will return an object that will be our stopwatch object. Let’s look at this step-by step. First we create the outer anonymous function and auto-execute it. For now we’ll have the function return an empty object.

var stopwatch = (function () {
  // other code to be added here
  return {
    // define some fields
  };
}());

Nothing too drastic so far, I’m sure you’ll agree. Now the fun bit starts. Let’s add back the original stopwatch code, altering it so that it makes sense as local variables and nested functions.

var stopwatch = (function () {
  var startTime = -1,

  now = function () {
    return +new Date();
  },

  start = function () {
    startTime = now();
  },

  stop = function () {
    if (startTime === -1) {
      return 0;
    }
    var elapsedTime = now() - startTime;
    startTime = -1;
    return elapsedTime;
  };

  return {
    // define some fields
  };
}());

As you can see all of those annoying this references have gone since there is no enclosing object any more. Instead we can rely on function scope to resolve references to variables. For example, in the start() function we can reference the outer anonymous function’s startTime local variable. For that matter, the same applies to the stop() function. The final step is to make sure that the returned object has the required two methods, start() and stop().

var stopwatch = (function () {
  var startTime = -1,

  now = function () {
    return +new Date();
  },

  start = function () {
    startTime = now();
  },

  stop = function () {
    if (startTime === -1) {
      return 0;
    }
    var elapsedTime = now() - startTime;
    startTime = -1;
    return elapsedTime;
  };

  return {
    start: start,
    stop: stop
  };
}());

The code that creates the new returned object looks a little weird until you read it as “this new object has a stop property whose value is the internal stop() function object, etc.”

The returned object makes use of the closure formed by the anonymous function. The object’s two properties (methods) will call the nested functions inside the closure and those, in turn, will make use of the outer function’s local variable startTime. We’ve essentially created some private members: a local variable and a now() function. These two members are inaccessible outside of the closure.

It must be admitted that the code as written assumes that our stopwatch object is going to be a singleton; after all, we’re auto-executing an anonymous function and it’s hard to do that twice in a row. If you have need of several stopwatches, then the best thing is to assign that anonymous function to a variable called createStopwatch, and then you can call it ad nauseam to create as many stopwatches as you’d like.

var createStopwatch = function () {
  // same code as before
  return {
    start: start,
    stop: stop
  };
};

var stopwatch1 = createStopwatch();
var stopwatch2 = createStopwatch();

Next time, we’ll take a look at how to augment an object created with the module pattern.

Launch your application faster with Okta’s user management API. Register today for the free forever developer edition!

Topics:

Published at DZone with permission of Julian Bucknall, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}