Singleton to Prototype Design Guidelines

This is a series of posts that explains some of the fundamental rules for developing complex JavaScript applications.

I am a real bugger when it comes to how my code is organized. Given the advanced user interfaces that we have today I have often noticed that JavaScript developers have become, for lack of a better adjective, bloody lazy!  Before we get into the singleton design patter a short discussion is warranted on when a singleton should be used versus a class that supports instantiation.

The most common examples of a singleton are existing JavaScript frameworks such as ExtJs, jQuery, etc. In essence we would only ever have a single instance of each of these frameworks each represented by its own unique namespace Ext and $ respectively. The other most common example of the singleton pattern is the root namespace that represents your JavaScript application because you would under most circumstances only have one. Note I said most circumstances.  There is often the case in the real world where a requirement initially requires a singleton pattern but over time it becomes evident that a class instance would be better.  The golden rule of ‘the only constant is change’ should always be kept in mind when designing your code structures. The purpose of this post is to demonstrate how to effectively use the singleton pattern properly and in such a way as to allow for the easy migration to a class pattern. The secondary goal is to show how writing your singletons in this fashion leads to consistency of code which is something we should all strive for!

First let’s look at the basic singleton design pattern that I often see exemplified on the web.

var mySingleton = {
                 globalVar1 : null,
                 globalVar2 : null,
                 myMethod1 : function(){},
                 myMethod2 : function(){}
 }

So I will state this very clearly and strongly, the above is NOT a singleton.  In my opinion this is a simple object that does nothing more provide a hierarchical structure of variables and methods under a root namespace.  For starters this pattern does NOT use closures and does not have the concept of private/protected vs public methods and variables. At a minimum the singleton design pattern should be written as follows.

Continue reading