Question

Prototypal object creation in JavaScript is claimed to be powerful (I hear it is efficient and if used correctly very expressive). But for some reason I find that it trips me up much more often than it helps me.

The main problem I have with patterns for object creation involving prototype is that there is no way to bypass the need for this. The main reason is that objects that are anything beyond very primitive, for example objects that populate themselves through asynchronous API calls, this breaks down due to change of scope.

So, I use prototypal object creation for objects that I know everything about from the beginning.

But for objects that need to do for example API calls to keep themselves up to date I completely skip prototype and use straight up object literals.

When I feel the need for extending one of these objects, I have used parasitic inheritence:

var ROOT = ROOT || {};

ROOT.Parent = function () {
    var self = {
        func1 : function () {
            alert("func1")
        };
    }
    return self;
};

ROOT.Child = function () {
    var self = ROOT.Parent(); // This is the parasitizing

    self.func2 = function () {
        alert("func2")
    };

    return self;
};

var myChild = ROOT.Child();
myChild.func1(); // alerts "func1"
myChild.func2(); // alerts "func2"

Using this pattern, I can reuse the code for func1 in the ROOT.Child object. However if I want to extend the code in func1 I have a problem. I.e if I want to call the code in the parents func1 and also my own func1 this pattern presents a challenge. I cannot do this:

ROOT.Child = function () {
    var self = ROOT.Parent();

    self.func1 = function () {
        alert("func2")
    };
};

Since this will completely replace the function. To solve this I have come up with the following solution (which you can also check out here: http://jsfiddle.net/pellepim/mAGUg/9/).

var ROOT = {};

/**
 * This is the base function for Parasitic Inheritence
 */
ROOT.Inheritable = function () {
    var self = {
        /**
         * takes the name of a function that should exist on "self", and
         * rewires it so that it executes both the original function, and the method
         * supplied as second parameter.
         */
        extend : function (functionName, func) {
            if (self.hasOwnProperty(functionName)) {
                var superFunction = self[functionName];
                self[functionName] = function () {
                    superFunction();
                    func();
                };
            }
        },

        /**
         * Takes the name of a function and reassigns it to the function supplied
         * as second parameter.
         */
        replace : function (methodName, func) {
            self[methodName] = func;
        } 
    };

    return self;
};

/**
 * "Inherits" from ROOT.Inheritable
 */
ROOT.Action = function () {
    var self = ROOT.Inheritable();
    /**
     * I intend to extend this method in an inheriting object
     */
    self.methodToExtend = function () {
        alert("I should be seen first, since I get extended");  
    };
    /**
     * I intend to replace this method in an inheriting object
     */
    self.methodToReplace = function () {
        alert("I should never be seen, since I get replaced.");
    };
    return self;
};

/**
 * "Inherits" from ROOT.Action.
 */
ROOT.Task = function () {
    var self = ROOT.Action();

    self.extend('methodToExtend', function () {
       alert("I successfully ran the extended code too.");
    });

    /** 
     * I know it is completely unecessary to have a replace method, 
     * I could just as easily just type self.methodToReplace = function () ...
     * but I like that you see that you are actually replacing something.
     */
    self.replace('methodToReplace', function () {
        alert("I successfully replaced the \"super\" method.");
    });

    return self;
};

var task = ROOT.Task();

task.methodToExtend(); // I expect both the "base" and "child" method to run.
task.methodToReplace(); // I expect only the "child" method to run.

Ok, so I should ask a question. Am I completely off target here or am I on to something? What are the apparent drawbacks?

Answer 1

No, you’re not off target. But you did not invent that wheel also. That type of ECMAscript inheritance became very famous with Doug Crockfords book Javascript: The good parts.

It is a nice pattern and uses closures nicely to keep things private and protected. However, it’s still up to you which patterns you prefer (plain prototypal inheritance, pseudo-classical).

With ES5 and new possiblitys like Object.create() and Object.defineProperties(), Object.freeze() to name a few, we also have good ways to have protection and privacy with a more prototypal approach. Personally, I still prefer and like the pseudo classical way, using closures to do stuff.

The caveat still might be function-calls overhead which you generally can avoid using a plain prototypal inheritance. We need to make a whole lot more calls to get things properly done (if things grows). Still, closures are considered to be a little memory greedy and probably be a reason for leaks if we use them sloppy or forget to clean up references here and there. I don’t have any reference for this now, but I strongly believe that the latest js engines are not much slower using closures like a lot.