使用闭包还是常规构造函数来创建私有属性？

Question

I've heard that one of the advantages of closures is the ability to create private properties for objects as follows.

function Func2(){
    //A is a closure, kept alive after the Func2 has returned, 
    //After Func2 returns, A is only accessible by getA and setA (it's "private")
    var A = 100;
    return {
        getA: function(){
            return A;
        },
        setA: function(newA){
            A = newA;
        }
    }
}

You can get and set the private property A of an object created with Func2 using the getter and setter functions...

var obj2 = Func2();
obj2.getA();
obj2.setA(200);

But what's the point of that if I can do the same thing using a regular constructor function?

function Func1(){ 
    var A = 100; //A is a private property of any object created with the Func1 constructor
    this.getA = function(){
            return A;
            };
    this.setA = function(newA){
        A = newA;
    };
}

Accessing the private properties is done the same way...

var obj1 = new Func1()
obj1.getA();
obj1.setA(200);

Answer 1

As others have pointed out in the comments, a closure is created in both cases, and both will work.

I think the reason that the return approach is recommended for the module pattern is that the module pattern does not make use of Javascript's prototype chain, so it's unnecessary to use a regular constructor function that would create a new prototype (which isn't needed and would waste memory). In your example, objects created by Func2 would just have the default prototype of Object.prototype , whereas objects created by Func1 would have a prototype of Func1.prototype which in turn would have the prototype Object.prototype . Also, Func2 has the advantage that it will work with or without the new keyword (although it's best to avoid the new keyword if you're using the module pattern for the reasons I mentioned above). (I have seen some programmers complain about the fact that if a programmer forgets the new keyword in traditional OO Javascript, it can cause hard-to-detect bugs; I personally have never found this to be an issue though).

Another approach to private variables, as you're probably aware, is to simply prefix them with _ , eg:

function Func1() { 
    this._A = 100;
}

Func1.prototype = {
    constructor: Func1,

    getA: function(){
        return this._A;
    },

    setA: function(newA){
        this._A = newA;
    }
};

Personally I prefer this over the module pattern - the main goal of private variables is communication to other programmers, ie "this is an internal property; don't access it directly" - and the underscore prefix is a well-known convention. Private properties have never really been about 100% preventing access to those properties, just discouraging it (consider the fact that most programming languages allow you to access private properties using reflection if you really want to). And also, simply prefixing with an underscore allows you to easily have "protected" properties in addition to private ones (useful for sub-types / sub-classes). Making use of the prototype chain is also more memory-efficient, because you don't have multiple copies of the same functions for each instance.

But I do realize that in spite of the simplicity of the underscore naming convention, some programmers still prefer using the module pattern to really make private properties inaccessible from outside the closure. If you want to do that, then I'd recommend using the traditional module pattern, using the return statement as in your first example.

Another pattern you could consider, if you prefer to stick with the module pattern but still want to declare public properties as you go along (rather than in a return statement at the end), would be to create a new object and use that instead of this , eg:

function Func3(){ 
    var obj = {};
    var A = 100;
    obj.getA = function(){
        return A;
    };
    obj.setA = function(newA){
        A = newA;
    };
    return obj;
}

(By the way, for private methods , as opposed to private data properties, the underscore prefix isn't a necessity even if you're using the prototypal approach. The code sample in this answer is an example of this.)