Alternative Module Pattern
Okay, I still haven’t finished my event package yet, but I do have short article about a variation on the module pattern. I learned this from the conference this Saturday and Douglas Crockford’s talk. In my last article I showed the ‘begetObject’ method; the technique today will user a similar structure.
var myObject = function() { var F = function() {}, that = null; F.prototype = { somePublicVariable: true, somePublicFunction: function() { return that.somePublicVariable; } }; that = new F(); return that; }();
In this case, inside the Function ‘myObject’ a new Function ‘F’ is created. ‘that’ is initialized to null, but is accessible to all methods inside this closure, including anything you attach to the prototype of ‘F’. This is handy because maintaining the scope of the ‘this’ object can be complex or down-right impossible in certain cases. ‘that’ will always have the proper scope and anything inside the ‘myObject’ closure will have access to it. In the past, I have always used an initialization Function to properly set the ‘that’ (or in previous examples I used ’self’) variable to the newly created object. By using this technique, you do not need to use an initialization Function.
Like other module pattern Functions, this method does not effectively leverage the prototype Object. Each time you call ‘myObject’ a new memory footprint will be created for Functions and variables attached to the prototype of ‘F’, instead of a pointer to the Function defined on the prototype. I believe I will be adopting this technique when writing methods that I previously would have used the old module pattern for: static packages and/or objects initialized once (or just a few times).
I’m not clear on what you’re trying to accomplish here. The module pattern is used for singletons, meaning your outermost function should only be called once. When creating singletons, there’s no advantage to using the prototype, which is most useful for having multiple instances of the same object type. I suppose you could do this if you wanted a singleton to inherit from a type, but otherwise I don’t understand how one would use this technique and why it’s advantageous as compared the Crockford module pattern.
And your use of “that” is unnecessary:
var myObject = function() {
var F = function() {};
F.prototype = {
somePublicVariable: true,
somePublicFunction: function() {
return this.somePublicVariable;
}
};
return new F();
}();
Comment by Nicholas C. Zakas — November 18, 2007 @ 12:06 am
Nicholas,
‘that’ is actually the most important part of this module pattern improvement. ‘that’ is a scope safe variable that is available to all functions inside of the closure function that creates ‘myObject’.
In JavaScript, you can not guarantee when executing a function like ’somePublicFunction’ that the execution scope will be ‘F’. Especially, if you use timeouts or callbacks. However, you can guarantee ‘that’ always points to the appropriate object. Therefore, using ‘that’ instead of ‘this’ throughout the methods inside of the module pattern closure, ensures that you never have to worry about the current execution scope.
Comment by admin — November 18, 2007 @ 4:45 pm
That seems pretty cool - I like the idea of not having to do the _this = this all the time.
(also, you have a typo: somePublicFucntion, though, perhaps thats the name you intended
Comment by Mr Speaker — June 19, 2008 @ 2:07 am
Thanks Mr. Speaker… I fixed the typo.
Comment by Matt Snider — June 19, 2008 @ 9:35 am