Please login or register.

Login with username, password and session length
Advanced search  

Author Topic: Simple Design Pattern for Javascript Functions  (Read 586 times)

Keyrocks

  • Doug
  • ULTIMATE member
  • ******
  • Karma: 449
  • Posts: 6019
  • Semantically Challenged
    • snews.ca
Simple Design Pattern for Javascript Functions
« on: December 03, 2010, 07:53:15 PM »

I subscribe to several technical newsletters that come to me by e-mail. Every now and then, something useful appears in them.

In the most recent (Tues. Nov.30.10) newsletter from SitePoint Tech Times, Editor Louis Simoneau shared what he calls a "design pattern" he's developed over time for writing new javascript functions. I haven't used it yet but I figured I would share it here so it's available to anyone for future reference.

I thought it might be interesting to look at a JavaScript design pattern that I use a great deal. I settled on it gradually, over a period of time, absorbing and adapting influences from various sources, until reaching a pattern that offers the flexibility I need. Let me show you an overview, and then look at how it comes together:

Code: [Select]

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:
Code: [Select]

(function()
{
 ...
})();


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

Code: [Select]

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 [1], 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

Look at that first code example, and you can see what flexibility is offered by the structure of the enclosing scope.
It's nothing you can't do in any function, of course, but 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 -- exactly the same trick as going "self = this" to create a reference for inner scopes.

Other private variables, declared the same way, can share the uppercase convention if they define constant data (however declaration using const instead of var should be avoided, because it's not well-supported).

Private functions can be used to provide internal utilities:

Code: [Select]

function defined(x)
{
 return typeof x != 'undefined';
}


Then we can create public methods and properties, accessible to other instances, and to the outside:
Code: [Select]
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:
Code: [Select]

var options = {
 x : 123,
 y : 'abc'
};

this.define = function(key, value)
{
 if(defined(options[key]))
 {
 options[key] = value;
 }
};


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!

Louis Simoneau,
Editor, SitePoint Tech Times

Logged
Do it now... later may not come.
-------------------------------------------------------------------------------------------------
sNews 1.6 MESU | sNews 1.6 MEMU