11

What is the recommended approach for helper functions? I would like to choose one technique, and run with it to create my new "class".

Here are the design options I have pondered:

Option 1: Helper function in outer scope, invoke with context of instance

function createPane (pane) {
    // logic to create pane
    var proto = Object.create(this.paneList);
    $.extend(paneProto, pane);
    return paneProto;
}

Panes.prototype.initialize = function (panes) {
    var _this = this;
    _.each(panes, function () {
        _this.panes.push(createPane.call(_this, this));
    });
}
  • Pros: Simple syntax. createPane is not published on the instance.
  • Cons: createPane is accessible in other scopes.

Option 2: Helper function in closure, invoke with context of instance

Panes.prototype.initialize = (function () {

    function createPane (pane) {
        // same logic as last createPane
    }

    return function (panes) {
        // same logic as before - calls createPane
    }

})();
  • Pros: createPane is not published on the instance.
  • Cons: Lower readability and testability; Testing of this helper must occur in the scope of initialize.

Option 3: Prepend _ to name to indicate a private method

Panes.prototype._createPane = function (pane) {
    // same logic as last createPane
}

Panes.prototype.initialize = function (panes) {
    // same logic as last, except calls this._createPane
}
  • Pros: Implicit context of _createPane is the instance. Testability from the outside.
  • Cons: Exposing helper function on the instance.

Option 4: Helper functions as arguments

Panes.prototype.initialize = (function (createPane) {

    return function (panes) {
        // same logic as before - calls createPane
    }

})(function createPane () {
   // same logic as last createPane
});
  • Pros: createPane is not published on the instance. Helper functions lack access to each other.
  • Cons: Lower readability and testability; Testing of this helper must occur in the scope of initialize.
TaylorMac
  • 211
  • 1
  • 2
  • 4
  • see: [Are there any OO-principles that are practically applicable for Javascript?](http://programmers.stackexchange.com/questions/180585/are-there-any-oo-principles-that-are-practically-applicable-for-javascript) – gnat Apr 10 '14 at 18:07

2 Answers2

5

First JavaScript doesn't have Classes.

Second, your third option seems more rational to me, but it highly depends to your requirements as well. Also you should not be much worried about exposing the helper function. The pros of the solution totally justifies the compromise to me.

Third, your time as a developer is valuable; Don't make trivial tasks hard to implement, time consuming and more pron to human-errors. Simplicity of source code is a great feature itself.

Mahdi
  • 1,983
  • 2
  • 15
  • 25
  • 1
    Mahdi thank you. I am a long time JavaScript user and yes, that's the reason why I wrote "class" in quotes. Although, terminology is misleading, and many professional organizations refer to JavaScript's constructor functions as classes. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Introduction_to_Object-Oriented_JavaScript – TaylorMac Apr 30 '14 at 19:48
  • And thank you for the suggestion on simplicity. My question is more about scope than anything, accessibility. Strict vs. Loose. – TaylorMac Apr 30 '14 at 19:50
  • @TaylorMac You're very welcome, hope it helps. – Mahdi May 01 '14 at 05:26
  • 1
    @Mahdi, currenlty Javscript has classes. – Menai Ala Eddine - Aladdin May 03 '20 at 05:08
1

Statics belong on the Function IMO, in your case you have a private static, so ...

Panes._createPane=function(pane){}
Mark
  • 336
  • 1
  • 4