Andi Smith

Self Executing Anonymous Revealing Module Pattern

I thought as a way to kick this blog off I would share this JavaScript pattern with you which I've started using recently. I can't take any credit for this pattern - I discovered it on my Internet travels, so all thanks and kudos go to Elijah Manor on 'Enterprise jQuery'.

If you're good JavaScript developer you should be placing your code in a namespace. A namespace stops collisions with other JavaScript files, reduces the use of the global scope and generally makes things tidier. Having variables in the global scope is considered bad practice as the variable could be overwritten or modified by any other JavaScript code anywhere. The most common way of placing your code in a namespace would be in an object literal like this:

var example = {
  publicVariable: 'publicValue',
  publicMethod: function() {

  }
};

Here we have a variable called example (which becomes our namespace) and we are declaring all our variables and methods within this. If we wanted to know the value of publicVariable we would call example.publicVariable; if we wanted to execute publicMethod we would call example.publicMethod()

What is the difference between a method and a function? In JavaScript, a method is code that belongs to an object and which is able to interface with other code and data within that object (object-orientated). A function is code that sits outside of an object and can be called from anywhere. In the case of the example above, publicMethod() is associated with the object 'example', so it is therefore a method. It is, however, just a naming convention. JavaScript does not have (or have a need for) a type 'method', just a type 'function' which can be associated to an object.

If you wanted to separate your private and public methods and create a closure (a mini environment which has access to the namespaces' local variables even when the function is returned), you'd probably do this:

var example = (function() {
  var privateVariable = 'privateVariable';

  function privateMethod() {
    return 1;
  }

  return {
    publicVariable: 'publicValue',
    publicMethod: function() {
      //return privateMethod();
    }
  };
}());

Here we have changed our namespace in to a anonymous self executing function. We have created private variables and functions which are only accessible within this namespace, and public variables and functions which are returned by the self executing function making them accessible by our entire codebase. We can call example.publicMethod(), but we cannot call privateMethod() outside of the namespace. If we were to uncomment the line of code within publicMethod(), we would be able to execute privateMethod from within this namespace.

The following code is also self executing but sets out our namespace with a much tidier, modular feel. It's my new favourite way of organising my code and has quickly become my most used pattern. Obviously, you should always use the best pattern for the job - there are some good books to read about JavaScript patterns (such as 'Pro JavaScript Design Patterns' by Dustin Diaz and Ross Harmes).

(function(example, $, undefined) {
  var privateVariable = 'privateValue';

  example.publicVariable = 'publicValue';

  function privateMethod() {

  }

  example.publicMethod = function() {

  };

})(window.example = window.example || {}, jQuery);

Focussing first on our top and bottom lines, you can see our arguments in the function call, and the values for these arguments at the bottom when the function is executed. The first difference to be noted with this approach is that we now pass the namespace in to the function as a parameter. We check whether it already exists in the global namespace (window). If it does we pass the existing namespace so we can append to it. If it does not, we pass an empty object literal.

The second argument passes in our jQuery object, although it could pass in any favourite JavaScript library. As the code we are executing is in its own local scope, we can now use the $ variable safe in the knowledge that no-one else has declared $ for use as anything else. We also include an argument of undefined and pass in no correlating value which removes the threat of someone else redefining undefined.

Within the function itself you still get you get all the benefits of private and public variables and functions but you don't need to place all your public functions and variables in to a return object literal. This means your private functions can refer to your public ones without needing to specify the entire namespace (just example.publicMethod()), and you do not need to remember to use object literal notation - which makes for tidier code and less chance of missing a comma or two.

Finally, it's easy to expand. You can expand your module with more functions and variables just by including window.example = window.example || {}

Let me know what you think below, and be sure to read the original article by Elijah!