Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

What is this pattern called? Is this a variant of the Module pattern? I remember there's disadvantage to this pattern and it's related to memory usage.

var module = function() {

    this.Alert = function() {    
        alert("I'm a public");
    }

    function iamPrivate() {
         alert("not callable because I'm private");   
    }
}

var inst = new module();
inst.Alert();
share|improve this question
    
stackoverflow.com/questions/7471349/why-module-pattern Similar question, take a looksie has some useful info. –  Mercfh Feb 21 '13 at 19:29
add comment

1 Answer

I call that basic fundamental JS OOP. You have a function constructor, this.publicMethods and internal/"private" instance properties/methods that aren't exposed externally. The key win there is that it's clear to everyone what is expected to only be used by the instance internally and how the object is expected to be handled by external concerns.

It's very simple, and it works. Where people tend to go wrong with it is when they start doing things Java-bean-style, e.g.

function PersonConstructor(nameArg){

    var name = nameArg; //redundant since arg is same scope but here for clarity

    this.setName = function(newName){
        name = newName;
    };

    this.getName = function(){ return name; };
}

var jim = new PersonConstructor('Jim');

In general programming (barring compensated weaknesses in language design), this is completely irrational, pointless and murders OOP. In JS, you might as well just cut out the cruft and do this:

var jim = {
    name:'Jim'
}

Which of course is entirely okay if all you wanted was a basic data structure and not a proper piece of an OOP-based architecture. That's where Java goes wrong for me personally. When everything has to be in a class people start forgetting the point of the class construct in the first place.

Because after all if you're giving full, direct access to a property, it's just a wide open property and contributes nothing to what OOP gives you which is a clear separation of what data domain an object instance is responsible for and what points of contact other constructs are expected to have with it. It's about signalling intent so that people can understand each other's code better, not somehow magically protecting an object by adding a pointless layer of abstraction that just 100% exposes a property anyway. When you expose everything anyway, objects server as little more than namespaces to loosely group like-methods around and you're right back to the kind of pre-OOP spaghetti where all you're tracking is one method after another which is the thing that OOP was supposed to help you avoid in the first place.

The module pattern used as object constructor doing the same dumb thing, as I understand it here is more like this:

function PersonFactory(nameArg){

    return (function(){
        var name = nameArg;//also redundant since nameArg would persist anyway
        return {
            getName: function(){ return name; }
            setName: function(newName){ name = newName; }
        }
    })()

}
var jim = PersonFactory('Jim');

I don't see the point in doing this. It's basically the same closure/scoping mechanism that gives you that internal var property but you've lost the ability to apply prototypes to a function constructor. There may be other advantages to the module pattern I haven't read for carefully enough yet but it always struck me as being popular with people for object building who maybe haven't quite figured out JS OOP in it's entirety yet as I've often seen it used to reinvent core language mechanics that already had the problem covered.

At the end of the day {} for the most part (literals and function Constructor-built objects have slight differences in JS) gives you the same result as new Object(). It's just shorthand for creating a basic object with public methods attached in one step. In both cases you don't want to touch the instance's constructor or its prototype. Because it's Object in both cases and everything inherits from an Object instance at the top of the prototype chain. So basically the module pattern used this way is only limiting what you can do with your "constructor."

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.