JavaScript singleton pattern and 'this'

Question

After reading a large number of articles on a singleton template and performing some tests, I did not find the difference between a singleton template like this ( http://jsfiddle.net/bhsQC/1/ ):

var TheObject = function () { var instance; function init() { var that = this; var foo = 1; function consoleIt() { console.log(that, foo); } return { bar: function () { consoleIt() } }; } return { getInstance: function () { if (!instance) { instance = init(); } return instance; } }; }(); var myObject = TheObject.getInstance(); myObject.bar(); 

and code like this ( http://jsfiddle.net/9Qa9H/3/ ):

 var myObject = function () { var that = this; var foo = 1; function consoleIt() { console.log(that, foo); } return { bar: function () { consoleIt(); } }; }(); myObject.bar(); 

Both of them make only one instance of the object, both of them can have "private" members, that points to the window object in any of them. It is just that the latter is simpler. Please correct me if I am wrong.

Using a standard constructor like this ( http://jsfiddle.net/vnpR7/2/ ):

 var TheObject = function () { var that = this; var foo = 1; function consoleIt() { console.log(that, foo); } return { bar: function () { consoleIt(); } }; }; var myObject = new TheObject(); myObject.bar(); 

has the advantage of using that correctly, but it is not solitary.

My question is: What are the common advantages and disadvantages of these three approaches? (If that matters, I'm working on a web application using Dojo 1.9, so anyway this object will be inside Dojo require ).

Answer 1

Well, the real difference is the singleton build time. The second approach immediately creates a singleton, the first - only after it was called for the first time. Depending on what singleton might be needed in memory, this may affect your application. For example, you may need a singleton only if the user performs a specific action. Therefore, if the user does not, then it would be nice not to initialize the singleton at all.

Also, if the initialization of a singleton is computationally intensive, it would be nice to be able to defer this until you need a singleton.

Change And, as Yani said, the latter is not a single, so I did not discuss it.

Answer 2

I do not think that there really is a big practical difference between the first two.

The first with getInstance behaves as a singleton pattern in classic OOP languages ​​such as Java.

The second approach behaves more like a static class in the classical OOP languages.

Obviously, the problems they have are the same for all singletones (enough material if you look at google).

The latter approach doesn’t even actually use new - you return the object from the constructor. Obviously, this is not a singleton at all, and as such would be the preferred approach.

Answer 3

I like to build singletons like this:

 function FriendHandler(){ if(FriendHandler.prototype.singleton){ return FriendHandler.prototype.singleton; } if(!(this instanceOf FriendHandler)){ return new FriendHandler(); } FriendHandler.prototype.singleton = this; ... this.selectFriends = function(firstName){ ... }; } 

If you do:

 new FriendHandler() or FriendHandler() 

It always returns the same instance.

I wrote about this a few months ago: http://franciscomsferreira.blogspot.com/2013/01/how-to-write-maintainable-javascript-or.html