Common JavaScript Design Pattern - jQuery.doc.ready

0

Category :

Let me show you an overview, and then look at how it comes together:

function MyScript(){}
(function()
{
  var THIS = this;
  function defined(x)
  {
    return typeof x != 'undefined';
  }
  this.ready = false;
  this.init = function(
  {
    this.ready = true;
  };
  this.doSomething = function()
  {
  };   
  var options = {
      x : 123,
      y : 'abc'
      };
  this.define = function(key, value)
  {
    if(defined(options[key]))
    {
      options[key] = value;
    }
  };
}).apply(MyScript);

As you can see from that sample code, the overall structure is a function literal:
(function()
{
  ...
})();

A function literal is essentially a self-executing scope, equivalent to defining a named function and then calling it immediately:

function doSomething()
{
  ...
}

doSomething();

I originally started using function literals for the sake of encapsulation—any script in any format can be wrapped in that enclosure, and it effectively “seals” it into a private scope, preventing it from conflicting with other scripts in the same scope, or with data in the global scope. The bracket-pair at the very end is what executes the scope, calling it just like any other function.

But if, instead of just calling it globally, the scope is executed using Function.apply, it can be made to execute in a specific, named scope which can then be referenced externally.

So by combining those two together—the creation of a named function, then the execution of a function literal into the scope of the named function—we end up with a single-use object that can form the basis of any script, while simulating the kind of inheritance that’s found in an object-oriented class.

The Beauty Within

By wrapping it up in this way we have a construct that can be associated with any named scope. We can create multiple such constructs, and associate them all with the same scope, and then all of them will share their public data with each other.

But at the same time as sharing public data, each can define its own private data too. Here for example, at the very top of the script:

var THIS = this; 

We’ve created a private variable called THIS which points to the function scope, and can be used within private functions to refer to it

Private functions can be used to provide internal utilities:
function defined(x)
{
  return typeof x != 'undefined';
}

Then we can create public methods and properties, accessible to other instances, and to the outside:
this.ready = false;
this.init = function()
{
  this.ready = true;
};
this.doSomething = function()
{
};

We can also create privileged values—which are private, but publicly definable, in this case via the public define method; its arguments could be further validated according to the needs of the data:

var options = {
  x : 123,
  y : 'abc'
  };
this.define = function(key, value)
{
  if(defined(options[key]))
  {
    options[key] = value;
  }
};

THIS or That?

The enclosing scope of any function can be referred to as this, so when we define a named or anonymous enclosure, this refers to that enclosure at the top level; and it continues to refer to that enclosure from within its public methods.

But within private functions, this refers to the immediate enclosing scope (the private function), not the top-level enclosing scope. So if we want to be able to refer to the top-level scope, we have to create a variable which refers to it from anywhere. That’s the purpose of "THIS":

function MyScript(){}
(function()
{
   var THIS = this;  
   function defined(x)
   {
      alert(this);      //points to defined()
      alert(THIS);      //points to MyScript()
   }
}).apply(MyScript);

Wrapped Up!

All of these features are what makes the construct so useful to me. And it’s all wrapped up in a neat, self-executing singleton —a single-use object that’s easy to refer-to and integrate, and straightforward to use!


my thanks to:
http://blogs.sitepoint.com/2010/11/30/my-favorite-javascript-design-pattern/
http://blogs.sitepoint.com/2010/12/08/the-anatomy-of-a-javascript-design-pattern/

0 comments:

Post a Comment