Recently I began learning common JavaScript patterns and have a question about the module pattern.
Which notation (and why) is more convenient and preferred?
"Separated" notation:
var SeparatedApproachModule = (function() {
var _private = { };
var _public = { };
_private.doABarrelRoll = function() {
//Do a barrel roll here
}
_public.buttonDoABarrelRoll_Click = function() {
alert("I am doing a barrel roll!");
_private.doABarrelRoll();
}
return _public;
})();
"Aggregated" notation:
var AggregatedApproachModule = (function() {
var _private = {
doABarrelRoll: function() {
//Do a barrel roll here
}
};
var _public = {
buttonDoABarrelRoll_Click: function() {
alert("I am doing a barrel roll!");
_private.doABarrelRoll();
}
};
return _public;
})();
Also posting other common or personal approaches you use and their advantages is appreciated.
Personally, the most easy is to read, the better to remember later on. Instead of returning the object what I do is to exposed the object to the global scope:
(function(AsGlobal/*or you can name it Public*/){
// private
var ModuleHelper = {
log : function(message){/*do stuff*/}
}
// Public
AsGlobal.Module = {
save:function(userName){
//saving code
ModuleHelper.log('the user '+ userName +' saved the proyected');
}
}
})(window);// the object that expose my objects to global scope
Related
How can I return the whole object of the self-inv-function without returning every functions manually?
I want to try with the following solution which should normally work, however, it does not work:
var publish = (function() {
var pub = {};
pub.hello = function() {
return "test"
};
return pub;
}());
now "pub" must be callable by subscribe:
var subsribe = (function(pub) {
function hello() {
return pub.hello();
};
}(publish));
I loaded both files in the browser (pub first).
However:
Debugger says: ReferenceError: pub not defined.
I think you want to write them like this:
var publish = (function() {
var pub = {};
pub.hello = function() {
return "test"
};
return pub;
})();
var subsribe = (function(pub) {
function hello() {
return pub.hello();
};
console.log(hello());
})(publish);
However, keeping a global reusable collections of functions can be accomplished in other ways, more elegantly maybe :) (separate file with export, singleton decorated with those methods)
You can't.
There's no mechanism in JS to get a list of variables in the current scope.
Even if you could, it probably wouldn't be a good idea as there would be no way to distinguish between public and private variables.
There is no such a mechanism but you can do something like this:
var publish = (function() {
const me = this;
let publicMethods = ['hello', 'bye'];
// private
function _hello() {
return "test";
};
function _bye() {
return "end test";
};
publicMethods.forEach((methodName) => {
let privateMethod = eval('_' + methodName);
Object.defineProperty(me, methodName, {
get: function() {
return privateMethod;
}
});
});
return this;
}());
console.log(publish.hello);
console.log(publish.bye);
console.log(publish.hello());
console.log(publish.bye());
I came across code similar to this recently,
// Simplified example..
var Application =
{
MemberVar1: null,
MemberVar2: null,
Initialize: function ()
{
Application.MemberVar1 = 'Foo';
Application.MemberVar2 = 'Bar';
console.log("Initializing..");
Application.GetMemberVars();
},
GetMemberVars: function ()
{
console.log(Application.MemberVar1 + ' ' + Application.MemberVar2);
}
};
$(Application.Initialize);
What is the name of this pattern/method/style? Utilizing OOP principles without using a style I've seen before, such as prototyping. What are the benefits of this style as opposed to other popular ones?
It's a simple one-off object literal that's being created... they can contain functions... perhaps that's what threw you.
The last line merely passes the Application.Initialize function to jQuery as a $(document).ready callback function
In light of the comments below, this is what the code actually does (and how you can write it a lot shorter/easier)
$(function()
{
console.log("Initializing..");
console.log("Foo Bar");//replace this with variables you declare #top of anon. function if you want
});
As a module (you can find out more about the module pattern here):
var Application = (function()
{
var memberVar1, memberVar2,
getMemberVars = function()
{
return memberVar1 + ' ' + memberVar2;
};
return {init: function()
{
memberVar1 = 'Foo';
memberVar2 = 'Bar';
console.log('initializing...');
console.log(getMemberVars());
}};
}());
$(Application.init);
Application is now an object literal, with only 1 property (init): a function that, because it was declared within the scope of that IIFE, has access to all variables local to that scope. That's the magic of closures for you. You can easily add getters and setters for the member vars, too:
var Application = (function()
{
var memberVars = {},//turned into object literal...
getMemberVars = function(all)
{
var i;
if(typeof all === 'string' || typeof all === 'number')
{
return memberVars[all];
}
all = [];
for (i in memberVars)
{
if (memberVars.hasOwnProperty(i))
{
all.push(memberVars[i]);
}
}
return all;//or all.join(' '), as you please
},
get = function(name)
{
return typeof name === 'undefined' ? name : memberVars[name];
},
set = function(name, val)
{
memberVars[name] = val;
};
return {init: function()
{
memberVars.one = 'Foo';
memberVars.two = 'Bar';
console.log('initializing...');
console.log(getMemberVars().join(' '));
},
get: get,
set: set};//just add getter and setter here
}());
This has the same behavior as your code:
var Application = (function() {
var app = {
MemberVar1: null,
MemberVar2: null,
GetMemberVars: function() { /* ... */},
Initialize: function() {
this.MemberVar1 = 'Foo';
this.MemberVar2 = 'Bar';
console.log('Initializing..');
this.getMemberVars();
}
};
$(function() {app.Initialize();});
return app;
}());
But there's a good chance that you don't really want that Initialize function hanging around. So this would simplify it:
var Application = (function() {
var app = {
MemberVar1: null,
MemberVar2: null,
GetMemberVars: function() { /* ... */}
};
$(function() {
app.MemberVar1 = 'Foo';
app.MemberVar2 = 'Bar';
console.log('Initializing..');
app.getMemberVars();
});
return app;
}());
And unless you're actually worried about code trying to access Application.MemberVar1, etc before jQuery's document.ready event, you can simplify it further to this:
var Application = (function() {
var app = {
GetMemberVars: function() { /* ... */}
};
$(function() {
app.MemberVar1 = 'Foo';
app.MemberVar2 = 'Bar';
console.log('Initializing..');
app.getMemberVars();
});
return app;
}());
I'm assuming that defining those MemberVars took some real work, and were not simple strings as in the example. If that's not the case, then I would switch this last to
var Application = (function() {
var app = {
MemberVar1: 'Foo';
MemberVar2: 'Bar';
GetMemberVars: function() { /* ... */}
};
$(function() {
console.log('Initializing..');
app.getMemberVars();
});
return app;
}());
You don't need to use prototype if you are going to use only one instance of some object.
In this case it's pretty clear the Application object is something unique and the author didn't intend there were going to be any additional copies of Application created.
Talking about style... that capital camel case looks ugly. The common agreement is to use CapitalCamelCase only for object constructors. I personally think it's ok to use for unique objects with logic too (Application). But using it for function names and variables should be avoided.
Talking about patterns... it's close to Singleton pattern. But don't think too much about it. All those OOP patterns from Java world lose part of their appeal in JS world. Some of them disintegrate completely. Concentrate on JS ways of solving problems.
I have the following:
mod.a = (function() {
var myPrivateVar = 'a';
function myPrivateFct() {
//do something I will need in my sub-module (mod.a.b)
}
return {
//some public functions
}
})();
mod.a.b = (function() {
// some local vars and functions
return {
mySubModuleFct:function() {
// here I want to call mod.a.myPrivateFct();
}
})();
I want to create a sub-module and call a private function from my parent module mod.a. How can I do this while following the best practices of the module pattern?
A coworker showed me how to do it. It's actually very elegant.
mod.a = (function() {
var myPrivateVar = 'a';
function myPrivateFct() {
//do something I will need in my sub-module (mod.a.b)
}
return {
b: {
bPublicMethod:function() {
myPrivateFct(); // this will work!
}
}
//some public functions
}
})();
//call like this
mod.a.b.bPublicMethod(); // will call a.myPrivateFct();
I would suggest using John Resig's Simple Inheritance code for more object-oriented approach to javascript:
http://ejohn.org/blog/simple-javascript-inheritance/
It allows you to write this:
var Person = Class.extend({
init: function(isDancing){
this.dancing = isDancing;
}
});
var Ninja = Person.extend({
init: function(){
this._super( false );
}
});
var p = new Person(true);
p.dancing; // => true
var n = new Ninja();
n.dancing; // => false
After doing some reading about the Module Pattern, I've seen a few ways of returning the properties which you want to be public.
One of the most common ways is to declare your public properties and methods right inside of the "return" statement, apart from your private properties and methods. A similar way (the "Revealing" pattern) is to provide simply references to the properties and methods which you want to be public. Lastly, a third technique I saw was to create a new object inside your module function, to which you assign your new properties before returning said object. This was an interesting idea, but requires the creation of a new object.
So I was thinking, why not just use this.propertyName to assign your public properties and methods, and finally use return this at the end? This way seems much simpler to me, as you can create private properties and methods with the usual var or function syntax, or use the this.propertyName syntax to declare your public methods.
Here's the method I'm suggesting:
(function() {
var privateMethod = function () {
alert('This is a private method.');
}
this.publicMethod = function () {
alert('This is a public method.');
}
return this;
})();
Are there any pros/cons to using the method above? What about the others?
Your function has no object context, so this references to the global window object in this case. Every property you assign to this automatically pollutes the global namespace.
(function() {
console.log(this == window); // true
this.publicMethod = function () {
alert('This is a public method.');
}
})();
console.log(publicMethod); // function()
You can explicitly pass it an object to tell which context to use.
var MYAPP = {};
(function() {
// 'this' will now refer to 'MYAPP'
this.publicMethod = function () {
alert('This is a public method.');
}
}).call(MYAPP);
console.log(publicMethod); // undefined
console.log(MYAPP.publichMethod); // function()
Which you can write in somewhat other style:
var MYAPP = (function(my) {
var my;
⋮
return my;
})(MYAPP);
And we arrived to an already discussed pattern. For further details, see Dustin's article on Scoping anonymous functions.
I would recommend the style where you add your public properties and methods to an anonymous object that you then return:
var myModule = (function() {
function privateMethod() { ... }
function publicMethod() { ... }
return { publicMethod: publicMethod };
})();
if you want to publish methods, then do something like:
var export = (function() {
var privateMethod = function () {
alert('This is a private method.');
}
var export = {};
export.publicMethod = function () {
alert('This is a public method.');
}
return export;
})();
Another option is to avoid the this reference altogether. Define a function that creates and returns an anonymous object instead.
function makeThing(someAttribute) {
var privateVariable = 42;
function someMethod() {
return privateVariable;
}
return {
"publicMethodName": someMethod,
"getAttribute": function() {
return someAttribute;
}
};
}
var thing = makeThing(99);
thing.publicMethodName();
thing.getAttribute();
Revealing Module patterns:
var m1 = (function(){ return {method: mthod} })();
var m2 = new function Singleton(){ return {method: mthod} };
var m3 = ({}).prototype = {method: method};
var m4 = ({}).prototype = (function(){ ... })();
var m5 = (function(){}).prototype = {} || (function(){ ... })();
var m6 = (function(extendee){
return extendee.prototype = {attr3: 'attr3'};
})({currentAttr1: 1, currentAttr2: 2});
Also, if you need method-chaining:
var m = (function(){}).prototype = (function(){
var thus = m; // this
console.log('m this-------', thus);
function fn(){
console.log('fn', thus);
return thus;
}
function f(){
console.log('f', thus);
return 'poop';
}
return {f: f, fn: fn};
})();
console.log('M:', m, 'm.fn', m.fn(), 'm.fn.f', m.fn().f());
There's also plenty more ways, and you can protagonize your modules as well.
I've got a JavaScript "object", built this way:
function foo()
{
this.length = 0;
}
foo.prototype.getLength = function()
{
return this.length;
}
...
I know how to emulate namespaces with singleton JavaScript objects, but what is the best way to "namepace" an object such as that above that will intanced?
I know that several JavaScript libraries have namepacing capabilities, but I'm using jQuery and would rather not add another library to the mix. I'd like to be able to provide my own, perhaps by exploiting jQuery, intrinsic namespacing scheme for the JS objects of mine that need to be instanced.
Thanks
rp
Simple:
if(!MyNamespace) MyNamespace = {};
MyNamespace.foo = function() {
this.length = 0;
};
MyNamespace.foo.prototype.getLength = function() {
return this.length;
};
Javascript doesn't really have namespace or packages like other languages. Instead it has closures. If you have an application that consists of multiple functions, variables and objects, then you should put them inside a single global object. This will have the same effect as a namespace.
For example:
var namespace = {
this.foo: function(){
...
},
this.foo.prototype.getLength: function(){
...
}
}
You could also create a set of nested objects and simulate packages:
loadPackage = function(){
var path = arguments[0];
for(var i=1; i<arguments.length; i++){
if(!path[arguments[i]]){
path[arguments[i]] = {};
}
path = path[arguments[i]];
}
return path;
}
loadPackage(this, "com", "google", "mail") = {
username: "gundersen",
login: function(password){
...
}
}
this.com.google.mail.login("mySecretPassword");
Shouldn't be much different:
namespace.foo = function foo() {...}
namespace.foo.prototype.getLength = function() { ... }
or you could use
(function() {
function foo() { ... }
foo.prototype...
namespace.foo = foo;
})();
to save some typing.
Both answers were very helpful! Here's what I ended up with:
if( typeof( rpNameSpace ) == "undefined" ) rpNameSpace = {};
rpNameSpace.foo = function() {
this.length = 613;
}
rpNameSpace.foo.prototype.getLength = function() {
return this.length * 2;
}
Then, to use the resulting "namespaced" object:
var x = new rpNameSpace.foo()
display( x.getLength() );
Another alternative may be the bob.js framework:
bob.ns.setNs('myApp.myFunctions', {
say: function(msg) {
console.log(msg);
}
});
//sub-namespace
bob.ns.setNs('myApp.myFunctions.mySubFunctions', {
hello: function(name) {
myApp.myFunctions.say('Hello, ' + name);
}
});
//call:
myApp.myFunctions.mySubFunctions.hello('Bob');