Is javascript OOP?

The Module pattern is based in part on object literals and so it makes sense to refresh our knowledge of them first.

A JavaScript object literal is a comma-separated list of name-value pairs wrapped in curly braces.

The following demonstrates an example object literal:

We don't need the keyword new for initiation as we saw in constructor design pattern.

We can add new members (outside of the object) using this assignment
myModule.property = "someValue" .

Let's see a more complex difference bettween object literals and module patterns taken from stack overflow.

There is one guy that ask a question about his current website where he is using object literal pattern. Let's see an example of his code:


site.auth = {
init: function() {
site.auth.doms.loginButton.on('click', site.auth.events.onLoginButtonClicked);
},
doms: {
loginButton: $('.login'),
registerButton: $('.register')
},
events: {
onLoginButtonClicked: function() {
}
},
fbLogin: function() {
}
};

site.dashboard = {
};

site.quiz = {
};

// more modules



But with the above code two problem rise. The first is that all the methods are public and the second that he has to write code like site.auth.doms.loginButton and site.auth.events.onLoginButtonClicked.

So he tried the module pattern:


var site = (function() {
function init() {
$('.back-to-top').on('click', scrollToTop);
site.auth.init();
}

function scrollToTop() {
$('body').animate({scrollTop: 0}, 400);
}

return {
init: init
}
})();

site.auth = (function() {
var doms = {
loginButton: $('.login'),
registerButton: $('.register')
};

function init() {
doms.loginButton.on('click', onLoginButtonClicked);
}

function onLoginButtonClicked() {

}

return {
init: init
}
})();

// more modules

As we can see those long names are gone, but then he asks that he has to init all other modules in the site.init() function to construct them all? Then he has to remember to return the functions that need to be accessible by other modules?

The answer on this is that It's not a requirement of the revealing-module  to have an .init method, at all.
If a module can be self-contained, then just focus on exporting what you WOULD like to make public.

Like for example:


var testModule = (function () {

var counter = 0;

return {

incrementCounter: function () {
return counter++;
},

resetCounter: function () {
console.log( "counter value prior to reset: " + counter );
counter = 0;
}
};

})();

// Usage:

// Increment our counter
testModule.incrementCounter();

// Check the counter value and reset
// Outputs: counter value prior to reset: 1
testModule.resetCounter();


So in conclusion module pattern gice us th freedom to have private functions and private members which can only be consumed by our module. As they aren't exposed to the rest of the page (only our exported API is), they're considered truly private.

Given that functions are declared normally and are named, it can be easier to show call stacks in a debugger when we're attempting to discover what function(s) threw an exception.