This looks like the non-singleton version of the module pattern, whereby private variables can be simulated by taking advantage of JavaScript’s “closures”.
I like it (kinda…). But I don’t really see the advantage in private variables done in this way, especially when it means that any new methods added (after initialisation) do not have access to the private variables.
Plus, it doesn’t take advantage of JavaScript’s prototypal model. All your methods and properties must be initialised EVERY time the constructor is called – this doesn’t happen if you have methods stored in the constructor’s prototype. The fact is, using the conventional constructor/prototype pattern is much faster! Do you really think private variables make the performance hit worth it?
This kind of model makes sense with the module pattern because it’s only being initialised once (to create a pseudo-singleton), but I’m not so sure it makes sense here.
Do you use this kind of constructor pattern?
No, although I do use its singleton variant, the module pattern…
Do you find it understandable?
Yes, it’s readable and quite clear, but I don’t like the idea of lumping everything inside a constructor like that.
Do you have a better one?
If you really need private variables, then stick with it by all means. Otherwise just use the conventional constructor/prototype pattern (unless you share Crockford’s fear of the new/this combo):
function Constructor(foo) {
this.foo = foo;
// ...
}
Constructor.prototype.method = function() { };
Other similar questions relating to Doug’s views on the topic: