Javascript – Confused about javascript module pattern implementation

design-patternsjavascriptmodules

I have a class written on a project I'm working on that I've been told is using the module pattern, but it's doing things a little differently than the examples I've seen. It basically takes this form:

(function ($, document, window, undefined) {

    var module = {
        foo : bar,

        aMethod : function (arg) {
            className.bMethod(arg);
        },
        bMethod : function (arg) {
            console.log('spoons');
        }
    };
    window.ajaxTable = ajaxTable;

})(jQuery, document, window);

I get what's going on here.
But I'm not sure how this relates to most of the definitions I've seen of the module (or revealing?) module pattern. like this one from briancray

var module = (function () {
    // private variables and functions
    var foo = 'bar';

    // constructor
    var module = function () {
    };

    // prototype
    module.prototype = {
        constructor: module,
        something: function () {
        }
    };

    // return module
    return module;
})();

var my_module = new module();

Is the first example basically like the second except everything is in the constructor? I'm just wrapping my head around patterns and the little things at the beginnings and endings always make me not sure what I should be doing.

Best Answer

It's really a weird example, I've never seen a usage of a constructor to create a module this way. I would higly recommend you using the first solution, it creates just one scope and one object and that's all you need. The second one is used mainly when you need to export some constructor. And then you are allowed to use new Constructor() multiple times. However the first solution can be a little bit altered:

var module = new (function ($, document, window, undefined) {
  this.property = "hello";
})(jQuery, document, window);

console.log(module.property);

This allow you to create an IIFE which itself is a constructor so you get a new object based on this constructor. If you don't like the object literal based solution, this is a way to go.

Also you can take a look at AMD (using RequireJS) or CommonJS (using Node.js or Browserify) specifications which allows you to move every single module to its own file. Lots of libraries use these patterns. I prefer CommonJS and it's very simple. You have a file which represents a module and which has 3 additional predefined variables. They are exports, module and require.

// a.js
exports.property = "hello"; // Basically the same as the example above

// b.js
module.exports = function () { // Something similar to exporting a custom object
  console.log("hello");
};

// c.js
var a = require("./a"), b = require("./b"); // Loading these modules

console.log(a.property); // logs "hello"
b(); // also logs "hello"

Related Solutions

Helper in Programming – Design Pattern or Algorithm?

A Helper class is a lesser known code smell where a coder has identified some miscellaneous, commonly used operations and attempted to make them reusable by lumping them together in an unnatural grouping. Successive developers have then come onto the project and not realised that the helper class exists, and have consequently rewritten the same common operations, or even created more Helper classes.

But seriously, the main problem with Helper classes is that they are usually operations that act on a specific class, which obviously means in OO terms that they are suffering from an acute case of Feature Envy. This failure to package the behaviour with the data it acts on is why developers so often (in my experience) fail to find it.

In addition to this, as you have already identified SomethingSomethingHelper is actually a terrible name. It is undescriptive, and gives you no real inkling of what sort of operations the class does (it helps?), which also means that it's not obvious when adding new behaviours whether they belong in the Helper class or not. I would break up such classes along the lines of related behaviour that logically group together, and then rename the new classes to reflect what it does.

Design Patterns in JavaScript – Is Module Pattern Only for Singleton Creation?

I'd argue no-ish. I'm not sure it's really the "module pattern" if you return anything other than a singleton. But, you can certainly use the same "pattern" to accomplish other things.

The module protects the global scope from the internal variables used to build the return-value; but the return value can itself be a function -- including a constructor.

To that end, if you had a need for some sort of "private static" class member which you'd like all instances of a class to access, the module pattern can accomplish that.

As a silly example, suppose you're building a Counter class, wherein each individual Counter needs to track a certain event, but wherein you also want a protected TotalCountEvents across all Counter objects, you could do this:

var Counter = (function() {
  var totalcount = 0;

  var constructor = function() {
    var count = 0;
    this.increment = function() { count += 1; totalcount += 1; };
    this.getCount = function() { return count; };
  };

  constructor.getTotalCount = function() { return totalcount; };
  return constructor;
})();

You can then use it like this:

var counterA = new Counter();
var counterB = new Counter();

counterA.increment(); counterA.increment();
counterB.increment(); counterB.increment(); counterB.increment();

console.log(counterA.getCount(), counterB.getCount(), Counter.getTotalCount());

And you'll see:

> 2 3 5

But, access to the underlying totalcount will be restricted to instances of Counter.

^{Bear in mind, the factory pattern can accomplish the same sort of thing, just with stylistic/syntactic differences. Changing your factory to look like a "module" mostly allows you to create instances with new ... which is taboo in some circles anyway.}

Best Answer

Related Solutions

Helper in Programming – Design Pattern or Algorithm?

Design Patterns in JavaScript – Is Module Pattern Only for Singleton Creation?

Related Topic