One attempt of private methods in JS

Question

I've seen people trying to attempt implementation of private methods in JS. However they all have different issues, like this one: JavaScript private methods

I believe my attempt has some problems as well. But other than the overhead and caller is not allowed in strict mode, what are the problems with my implementation? You can see an working example in jsfiddle: http://jsfiddle.net/rabbit_aaron/oqpen8c8/17/

the implementation is also pasted here:

var CLASS = function () {
    this.publicFunctions = {};
    this.PROTOTYPE = {};
    var _class = function () {
        this.constructor.apply(this, arguments);
    };
    _class.prototype = this.PROTOTYPE;
    _class.prototype.validateAccess = CLASS.prototype.validateAccess;
    _class.prototype.constructor = function () {};
    _class.prototype.publicFunctions = this.publicFunctions;
    this.finalClass = _class;

    return this;
};

CLASS.prototype.validateAccess = function (caller) {
    if (this.publicFunctions[caller] !== caller) {
        throw 'Accessing private functions from outside of the scope';
    }
    return true;
};
CLASS.prototype.setConstructor = function (func) {
    this.PROTOTYPE.constructor = func;
};
CLASS.prototype.addPrivateFunction = function (name, func) {
    this.PROTOTYPE[name] = function () {
        this.validateAccess(this[name].caller);
        func.apply(this, arguments);
    };
    return this;
};

CLASS.prototype.addPublicFunction = function (name, func) {
    this.PROTOTYPE[name] = func;
    this.publicFunctions[this.PROTOTYPE[name]] = this.PROTOTYPE[name];
    return this;
};


CLASS.prototype.getClass = function () {
    return this.finalClass;
};

Some people just create a variable within a scope and assign a function to it. Very private. — Marvin Smit, Aug 14 '14 at 08:58
Seems hard to maintain. Why don't you use a simple module pattern ? — Sebastien C., Aug 14 '14 at 08:59
It just adds some complexity to your code but no protection to your private function. So I don't see any real advantage compared to e.g. prefixing a function with `_` and marking it private in the documentation using `jsdoc`. — t.niese, Aug 14 '14 at 09:04
How do I inherit from a child class? In your example I can see the `Person` class that inherits from CLASS. What if I wanted to make a `Lady` and `Gentleman` class that inherited from `Person`? — glenatron, Aug 14 '14 at 09:04
Also consider whether public and private stuff is even that important to have, given that it goes against the grain of the language: http://blog.millermedeiros.com/a-case-against-private-variables-and-functions-in-javascript/ — glenatron, Aug 14 '14 at 09:06
@sebcap26 Why is it hard to maintain, and, what is simple module pattern? — rabbit.aaron, Aug 14 '14 at 09:06
Shouldn't this question be posted on codereview.stackexchange.com ? — Sebastien C., Aug 14 '14 at 09:06
@glenatron Let me see if I can get it to work with inheritance — rabbit.aaron, Aug 14 '14 at 09:19
Please show us how to actually create a class with this helper. — Bergi, Aug 14 '14 at 10:01

score 1 · Answer 1 · answered Aug 14 '14 at 09:06

The first thing that comes to mind is that it is pretty simple to do the following in some code that gets loaded later on:

instanceOfSubClass.validateAccess = function (caller) {
    return true;
}

This effectively overrides validation. Pretty much all private variable tricks that don't involve using nested scoping to hide variables suffer from this problem. Of course, this is a pretty specific thing to have to know to do, so it depends on what you are trying to protect against. If you just want to protect against yourself in the future, then this might work fine, but if you are publishing a library that will be interacting with code you don't write and you want to ensure that it will always behave properly, then this isn't the way to go.

score 0 · Accepted Answer · edited May 23 '17 at 12:11

I believe my attempt has some problems as well.

Yes.

But other than the overhead and caller is not allowed in strict mode

I wouldn't call that a problem, I'd call it a no-go. Strict mode is supposed to be the default mode.

what are the problems with my implementation?

About your approach of making methods "private":

It's easy to circumvent your measures. Like @Austion you can simply override the validateAccess function, but you can also mess with the public publicFunctions object
It's only hiding methods, not fields. Making non-function properties private is often the more relevant goal, as these are containing the (protection-deserving) state of the instance.
It doesn't work in engines that have no Function::toString decompilation (there are a few old ones). Also, it doesn't work for methods that are programmatically created (as closures) and share the same body.

A few bugs in your implementation that are possible to fix:

private methods can't return a value
private methods can't call other private methods, only public methods can call them
this.constructor.apply(this, arguments); is a nice idea to make a settable constructor. However, it a) will fail horribly once you try inheritance (can be fixed by by calling _class.prototype.constructor) and b) corrupts the rule of thumb that fn.prototype.constructor == fn/Object.getPrototypeOf(instance)==instance.constructor.prototype

Remember, true privacy is only possible through the use of closures.

One attempt of private methods in JS

2 Answers2