views:

248

answers:

4

So there's this so-called module pattern for creating singletons with private members:

var foo = (function () {
    var _foo = 'private!';
    return {
        foo: function () { console.log(_foo); },
        bar: 'public!'
    }
})();

There's also this method that I found on my own, but haven't seen anything written about:

var foo = new function () {
    var _foo = 'private!';
    this.bar = 'public!';
    this.foo = function () { console.log(_foo); };
}

I'm thinking there must be a reason why nobody writes about this while there's tons of articles about the module pattern. Is there any downside to this pattern? Speed, or browser compatibility perhaps?

A: 

I don't see any substantial difference between the two. I would prefer the latter simply since it has much less punctuation clutter.

On the other hand the "module pattern" approach seems to be the most common and is becoming a well known pattern (due to the rise in JQuery). It might be better to stick with this recognised pattern not because it has any more technical merit than the other approach but just because it will likely be more recognizable (despite the heavy punctuation).

AnthonyWJones
I don't think it's entirely or even mainly due to the rise in jQuery: it's been around for longer than that.
Tim Down
@Tim: You're right is isn't "entirely" down to JQuery ;)
AnthonyWJones
A: 

Douglas Crockford writes about the second one. As Greg says in his comments, I thought it was quite common, and I've used it in the past.

Edit: to actually answer your question - there's no downsides, the two are functionally equivalent (both create a closure containing the "private variables" and exposing other variables/methods publically), and have exactly the same browser support and performance characteristics. It just comes down to a matter of syntax - basically, where you put the () to actually invoke this function and get your closure, and whether you use the new keyword.

Andrzej Doyle
Actually Douglas Crockford is against the second one. `It is never a good idea to put new directly in front of function. For example, new function provides no advantage in constructing new objects.`http://yuiblog.com/blog/2006/11/13/javascript-we-hardly-new-ya/
Protron
+1  A: 

More-or-less, they give you the same result. It's just a matter of which path you want to take for it.

The 1st may be more popular since it's simply the mixture of 2 already common patterns:

(function closure() {
    var foo = 'private';
    /* ... */
}())

var singleton = {
    bar : 'public'
};

However, prototype chaining would be the benefit of the 2nd pattern since it has its own constructor.

var singleton = new function Singleton() { };
assert(singleton.constructor !== Object);

singleton.constructor.prototype.foo = 'bar';
assert(singleton.foo === 'bar');
Jonathan Lonowski
+1 for prototype chaining mention
DVK
+2  A: 

You should see what Douglas Crockford thinks about this

By using new to invoke the function, the object holds onto a worthless prototype object. That wastes memory with no offsetting advantage. If we do not use the new, we don’t keep the wasted prototype object in the chain. So instead we will invoke the factory function the right way, using ().

So, he (the most quoted man on javascript) says that you should use the first method, and you have his reasons there.

Protron