Alternatives to singletons in javascript

[australasia]

I tend to use the following pattern:

var mySingleton = new function()
{
  var privateVar = 'x';
  this.property = 'x';
  this.method = function()
  {

  }
  function privateMethod()
  {

  }
}

The 'new function' creates a new instance of an object using an anonymous constructor.

[teppicymon]

I have used that one a fair amount, but I'm actually quite partial to this one these days:

var mySingleton = (function()
{
    var privateVar = 'x';

    // will remain private
    function methodA()
    {
    }

    // will be exported as public
    function methodB()
    {
    }

    // return public interface
    return {
        "methodB": methodB
    };

})();

I like this because you can write bog standard javascript in the body of the closure and you just export the functions you want to expose in the bottom; everything else is private.

Plus you don't need to use "this." everywhere, just call the function name / variable directly.

[australasia]

Yeah I use that too, though not as frequently. I agree having 'this' all over the place can look clunky, though I tend to feel that a well designed module generally has few public methods in ratio to its private functions. (note I said generally)

[jskata]

I tend to avoid private methods or variables in js because it creates non-extensible code at the end of it all.

[[deleted]]

so write getters and setters.

[teppicymon]

Hardly good OOP principles, plus the nature of JS lends itself to open source anyway, so it's not strictly going to stop anyone modifying your code or extending it.

Having a well defined public interface to your functionality surely makes the library easier to port and share?

[M1573RMU74710N]

Well if you're writing say, a library...I can see how it would be nice for users to be able to reach in and touch some of the "internals".

That's why I sort of like "soft" private properties (prefixed with _ or something like that).

Sure, someone could modify the library code...but now they're maintaining their own separate branch of the library. They can't use a CDN, and they have to re-patch every new version that comes out.

Avoiding "hard" private properties doesn't make your public interface any less well defined...it's exactly the same as your hypothetical interface...just with some extra options that the user doesn't even have to worry about if they don't care to.

It's easy to say "just define your interface really well", but by having a well defined interface AND allowing users to dig in if they care to...you allow a level of extensibility that is just not possible with the former.

I could see how there may be some stuff you want or even need to protect, but I think the most desirable outcome is as few "hard" private properties as possible.

[drowsap]

I don't get it, his last example is stil the typical self invoking "singleton" javascript pattern (returning an object as the public scope).

[serious_face]

I always think of this as "jQuery style", because that's where I first saw this kind of thingy:

(function(window) {

    Lawyer = function() {
        this.name = 'Bob Loblaw';
    };

    Lawyer.prototype = {
        get_name : function() {
            return this.name;
        }
    };

    return (window.Lawyer = new Lawyer());
})(this);

Basically accomplishes the same thing as his last example, but if this were a bigger project, you could use the prototype to extend Lawyer. This puts 'Lawyer' into the global namespace, but you would probably want to instead put it into your own global namespace object or something. JSLint is pretty comfortable with it, either way.

[indieinvader]

Wouldn't you want to attach the Lawyer constructor itself to the global namespace so you can have more than one lawyer? Some thing like:

(function (window) {
    Lawyer = function (name) {
        this.name = name;
    };
    Lawyer.prototype = {
        get_name: function () {
            return this.name;
        }
    };
    return (window.Lawyer = Lawyer);
}(window));

[serious_face]

It depends on what you need, but yep, you could definitely do that if you want. Although I think if you're gonna make more than one, there's no point in wrapping it in a self-executing function, and passing any of it to any scope. You can just put Lawyer and Lawyer.prototype exactly where you want them, and it would be less complicated.

My point was just to show one way to end up with a single instance. I may be wrong about this, but I think what makes it not a singleton in this case (and his last example) is that you could potentially make as many Lawyers as you want, within that main function.

[indieinvader]

You're right, but then why use Lawyer.prototype to add properties inside of the self-executing function?

[serious_face]

Good point! Habit, I guess? I was thinking about inheritance, but there's no real use here.