More Revealing Module Patter in Javascript

Question

It is known a Revealing Module Pattern in javascript, and here it is a little example.

var Module = (function(){
 var a = 3,
 init = function(a_user){ a = a_user; },
 update = function(){},
 get = function(){return a},
 set = function(a_user){ a = a_user; };
 return {
 init : init,
 update : update,
 get : get,
 set : set
 }
})();

It's good for lots of uses. But I modified it in 2 steps, and some people tell me that I've overloaded it, and my new variations take lots of memory. So I ask, if my variations are really bad, and I shouldn't use it?

Variation 1

I like to separate public and private logic. It's useful, because I separate methods, which I allow to users of my module (in the client code).

For example:

var MyModule = (function(){
 var
 pr = {}, // Private Scope
 PU = {}; // Public Scope
 pr.fetch = function(){}; // fetching data
 pr.build = function(){}; // building DOM of module
 pr.show = function(){}; // showing our object
 pr.hide = function(){}; // hiding our object
 //... Other private methods
 // Public methods
 PU.init = function(){
 pr.fetch().build().show();
 return PU; // for making chains
 } 
 PU.update = function(){};
 //... other Public methods
 return PU;
})();

I know, that in usual Revealing Module Pattern methods that are in last return are public, but other - private. But when you calling private method there, you just type it name, and it's unknown if it is a private method of this module, or it's a global function, that's why I have separated object - pr and PU.

Variation 2:

Sometimes I had need to insert some of modules twice on a page (or maybe more). So, I understand that it's not a module anymore, because Module can't have instances, Module is just a bundle of related functions. But I've decided to make a Module that can generate instances of itself. I've used my code from Variation 1 with a little fix:

var MyModule = function(){
 var
 pr = {}, // Private Scope
 PU = {}; // Public Scope
 pr.fetch = function(){}; // fetching data
 pr.build = function(){}; // building DOM of module
 pr.show = function(){}; // showing our object
 pr.hide = function(){}; // hiding our object
 //... Other private methods
 // Public methods
 PU.init = function(){
 pr.fetch().build().show();
 return PU; // for making chains
 } 
 PU.update = function(){};
 //... other Public methods
 // Constructor
 PU.__construct = function() {
 // constructor code
 return PU;
 }
 return PU.__construct.apply(this, arguments);
};
// Usage:
var m1 = new MyModule(/* some options*/);
m1.init();
var m2 = new MyModule(/* other options */);
m2.init();

Are these variation really bad? Should I avoid them, as some people have said to me some time earlier...

Answer 1

There's nothing really wrong with variation 1, but there's also no point in putting things in pr. Sure you can chain it, but why chain something where this only refers to half the stuff you need (the private stuff)? You might as well just use function declarations. And you can get rid of PU, since it's kind of a meaningless variable name:

var MyModule = (function(){
 function fetch(obj){}; // fetching data
 function build(obj){}; // building DOM of module
 function show(obj){}; // showing our object
 function hide(obj){}; // hiding our object
 //... Other private methods
 return {
 // Public methods
 init: function(){
 show(build(fetch(this)));
 return this; // for making chains
 },
 update: function(){}
 // ... other Public methods
 };
})();

The problem with variation two is that you create those functions whenever the constructor is called (so, more than once).

The normal way to avoid this is to do something like

var MyModule = (function(){
 function fetch(obj){}; // fetching data
 function build(obj){}; // building DOM of module
 function show(obj){}; // showing our object
 function hide(obj){}; // hiding our object
 function MyModule(){ 
 // constructor code
 };
 MyModule.prototype.init = function(){
 show(build(fetch(this)));
 return this;
 }; 
 MyModule.prototype.update = function(){};
 //... other Public methods
 return MyModule;
}());

Does that make sense?

This is not really a "module" anymore, by the way, just a normal constructor with some function properties attached to the prototype. But it looks like that's what you want, since you need multiple instances of it.