A disadvantage of this pattern is that if a private function refers to a public function, that public function can't be overridden if a patch is necessary. This is because the private function will continue to refer to the private implementation and the pattern doesn't apply to public members, only to functions.

Does anyone have an example of what he means by this?

Link to the Revealing Module Pattern referenced above

A disadvantage of this pattern is that if a private function refers to a public function, that public function can't be overridden if a patch is necessary. This is because the private function will continue to refer to the private implementation and the pattern doesn't apply to public members, only to functions.

Does anyone have an example of what he means by this?

Link to the Revealing Module Pattern referenced above

• javascript
• revealing-module-pattern

• It means that doing something like myRevealingModule.increment = newFunction; doesn't change the inner workings of the module. myRevealingModule.start will still call the internal, private increment function. This can be good or bad, depending on the context. – Felix Kling Commented Feb 21, 2014 at 6:12
• so "a patch" in this case, is it called Monkey Patching, or why is a patch like that necessary -- to fix a bug or to do something just to alter the object's behavior? – nonopolarity Commented Mar 28, 2014 at 21:11

3 Answers 3

Compare an object created by using an object literal to one created by the Revealing Module Pattern.

Here is one created as an object literal.

function makeGreeter(name){
  return {
    getName: function(){ return name;},
    sayHello: function(){console.log("Hello, " + this.getName());}
  }
}

var greeter = makeGreeter("Danny");
greeter.sayHello; // "Hello, Danny"
greeter.getName = function(){ return "George";}
greeter.sayHello(); // "Hello, George"

When you override the public method getName on the returned object, the sayHello method which depends on getName picks up the change. This is because in the Object Literal style, references to public functions are made via this, the returned object.

However, when you use the Revealing Module Pattern,

function makeGreeter(name){
  var getName = function(){ return name;},
    sayHello = function(){console.log("Hello, " + getName());};
  return {
    getName: getName,
    sayHello: sayHello
  }
}

var greeter = makeGreeter("Danny");
greeter.sayHello; // "Hello, Danny"
greeter.getName = function(){ return "George";}
greeter.sayHello(); // "Hello, Danny"

The RMP greeter will not pick up the override to the public getName method. This is because when RMP functions reference other functions (both public and private), they refer to the private closure copy rather than to the public function attached to the returned object.

It is for this reason I regard the Revealing Module Pattern as an anti-pattern.

I would bind getName to this, which, it seems, points to the content returned in RMP.

function makeGreeter(name){
    this.getName = function(){ return name;};
    var _sayHello = function(){console.log("Hello, " + this.getName());};
    return {
            getName: getName,
            sayHello: _sayHello
    }
}

I prefer this, though:

function makeGreeter(name){
    this.getName = function(){ return name;};
    var _sayHello = function(){console.log("Hello, " + this.getName());};
    var API = {
        getName: getName,
        sayHello: _sayHello
    };
    return API;
}

The answer given by @I-Lin Kuo looks good, but for one case creates the confusion.

function makeGreeter(name) {
return {
    getName: function() {
        return name;
    },
    sayHello: function() {
        console.log("Hello," + this.getName());
    }
  }
}

var greeter = makeGreeter("Danny");
greeter.sayHello(); //"Hello,Danny"
greeter.getName = function() {
    return "George";
}
greeter.sayHello(); //"Hello,George"

Instead of greeter.sayHello it should have been greeter.sayHello(). Creates a lot of confusion.