JS Revealing Module Pattern

The Revealing Module Pattern is called "revealing" because it exposes just its public parts through the return-object.

In text-area below you can try out the example code by pressing the "Run" button, and you can also modify it.

I call the function animal a "module" because it contains nested functions, and it returns an object that has been built inside.

Every local variable inside animal, like belly or species, will survive the function call when it is referenced by the returned object in some way (and thus is in its closure). We could call such variables private instance-fields. The same for inner functions. None of the private variables and functions, like belly or getBelly(), is visible or accessible from outside.

On the other hand, any function and variable in the return-object is public. They could be overwritten by any callee, simply assigning another function to the function's name. But mind that these overrides do not have access to the private parts of the module. Also the private functions can not call the public ones, because these are just in the return object on bottom, and that object does not have a name that could be referenced.

Code inside Return

var animal = function(givenSpecies)
{
  var species = givenSpecies;
  var belly = "nothing";

  return {
    hasEaten: function() {
      return belly;
    },
    eat: function(food) {
      belly = food;
    },
    toString: function() {
      return species+" has eaten "+belly;
    }
  };
};

(1) First drawback is that private functions can not call the public ones, because these are in an anonymous return object.

(2) Second drawback is that functions inside the return-object can call each other only by specifying this, it would not work without:

var animal = function(givenSpecies)
{
  ....

  return {
    hasEaten: function() {
      return belly;
    },
    ....
    ,
    toString: function() {
      return species+" has eaten "+this.hasEaten();
    }
  };
};

(3) Third drawback is that you increase the nesting level. The deeper the nesting level, the more the problem of global variables comes into sight (nobody knows why they have a wrong value at the right time:-). The more lines of code see a variable, the more side-effects will take place, the more unstable everything will be. Holding variable values is the primary reason for encapsulation, but having deeply nested inner logic below is counterproductive.

var animal = function(givenSpecies)
{
  var belly = "nothing";

  ....

  return {
    sound: function() {
      return {
        loud: function() {
          // belly is read/writable here 
        },
        quiet: function() {
          // belly is read/writable here 
        }
      };
    },
    ....
  };
};

Mind that a variable like belly is visible and writable anywhere inside the animal() function, even in the deepest nested object or function.

Always try to keep the nesting level of your JS code as low as possible. It will get unreadable else, and variables in upper scopes will get uncontrollable.

Singletons prevent Inheritance

var animal = (function(givenSpecies)
{
  ....

  return {
    ....
  };

})();

The difference to the pattern above is that animal now is an object-instance. You can not call it any more as function to produce a new instance. It is an IIFE.

The resulting animal object is called singleton. Such is also used in object-oriented languages, but just in special cases. A singleton reduces the functionality to just one instance. If you replace functions or properties on it, the singleton instance itself would be changed. The only way to use a JS singleton for inheritance is copying it, but then you may copy a particular state of the singleton.

Instantiation modules, or let's call them factory functions, are much more useful than singletons. In the following code, animal is extended to be a named cat. Try out this example, it shows that different instances can have different food in their private belly.

var animal = function(givenSpecies)
{
  var species = givenSpecies;
  var belly = "nothing";

  var getBelly = function() {
    return belly;
  };
 
  var setBelly = function(food) {
    belly = food;
  };
 
  var toString = function() {
    return species+" has eaten "+getBelly();
  };

  return {
    hasEaten: getBelly,
    eat: setBelly,
    toString: toString
  };
};

var cat = function(givenName)
{
  var name = givenName;
  var self = animal("Cat");

  var superToString = self.toString;

  self.toString = function() {
    return name+" "+superToString();
  };

  return self;
};

var garfield = cat("Garfield");
garfield.eat("mouse");
alert(garfield.toString());

var catbert = cat("Catbert");
catbert.eat("rat");
alert(catbert.toString());

In this example, a module cat extends animal. It instantiates animal, and then replaces its toString() function. To be able to reuse the super-implementation of toString(), it stores the old function-pointer into a local variable superToString before replacing it.

Do not make it difficult to reuse source code in JS modules by implementing them as singletons. But mind that a singleton would make sense when you have no instance variables, because you would not need to instantiate it before using it, and that makes life simpler. You could call this a "data-less module".

Naming the Return

The module cat looks different than animal. Here the return-object has a name, and that name could be referenced also by private functions.

Hence the named-return form would be preferable. So why not doing also the base object with a named return object? In the following the return-object is named self, but you can give it any name except JS reserved words like this. Some call it that, another good name would be instance.

var animal = function(givenSpecies)
{
  var species = givenSpecies;
  var belly = "nothing";
  var self = {};

  var getBelly = function() {
    return belly;
  };
 
  var setBelly = function(food) {
    belly = food;
  };
 
  var sound = function() {
    if (self.hasEaten() !== "nothing")  // call public from private
      return "hummm ...";
    return "grumble ...";
  };
 
  self.hasEaten = getBelly;

  self.eat = setBelly;

  self.sound = sound;

  self.toString = function() {
    return species+" has eaten "+getBelly(); // call private from public
  };

  return self;
};

var dog = animal("Dog");
alert(dog.toString()+", sounds: "+dog.sound());
dog.eat("sausage");
alert(dog.toString()+", sounds: "+dog.sound());

Mind that even if you override animal now and overwrite the hasEaten() function, the sound() implementation would work correctly by calling the replaced hasEaten(), not the original one.

Naming the return definitely is an advantage. Which now has led the Revealing Module Pattern to be what is called functional inheritance.

Now let's check if we have met our start-requirements. There is everything except the abstract function. But this is really easy: just call the function in super-object, and make sure that it is implemented then in the module that extends the super-object. The JS interpreter will search for the function only when it actually is launched, not before. In a strongly typed language like Java this would not be possible, but JavaScript is a rubber language :-)

JS Revealing Module Pattern

Requirements

Example Code

Code inside Return

Singletons prevent Inheritance

Naming the Return