Creating an object with privacy and prototyping(templating) similar to C++ class-private

Question

**EDIT - this was not stated explicitly in the answers...but you can not have private members that are "templated (i.e. not copied for each instance)" with out a self executing function. You will pay with processor time and code complexity for privacy

Like a C++ private class member.

I've been trying to determine what the defacto "hack" is for creating classes Seems like there are over 10 ways people are defining classes.

The type of class I'm looking for provides privacy and modularization and a templating mechanism. Javascript has prototype to create this templating mechanism. However the solution I am currently using below does not have private members.

If there isn't I have to ask the question what is the cost if I move all my javascript to this class type...where each is a self executing function? Now when my code loads it all has to be run before it can be used.

This cost is a trade-off for better programming practice. Now I have proper classes with privacy.

Is the cost worth it? Is the extra run time worth the privacy?

Here are some similar questions:

• How do I group similar methods and variables together in an object oriented approach?
• Creating a javascript object with prototyping (no privacy)
• https://stackoverflow.com/questions/8045897/should-i-consolidate-similar-methods-into-javascript-objectsassociative-arrays
• Constructors in JavaScript objects
• Wrapping a JavaScript "class" w/ out self execution?
• http://www.phpied.com/3-ways-to-define-a-javascript-class/

Current Method - lacks privacy...is spread out..ie. not enclosed in parantheses

var Message = function( div ) 
{
    this.div = document.getElementById( div ); 
};

Message.prototype.messages = 
{ 
    name:       'Please enter a valid name',
    email:      'Please enter a valid email',
    pass:       'Please enter passoword, 6-40 characters',
    url:        'Pleae enter a valid url',
    title:      'Pleae enter a valid title',
    tweet:      'Please enter a valid tweet',
    empty:      'Please complete all fields',
    same:       'Please make emails equal',
    taken:      'Sorry, that email is taken',
    validate:   'Please contact <a class="d" href="mailto:support@host.com">support</a> to reset your password'
};

Message.prototype.display = function( type ) 
{
    Control.sendInner( this.div, this.messages[type] );
};

Answer 1

Javascript has prototype to create this templating mechanism. However the solution I am currently using below does not have private members.

The only mechanism I know of to use prototypes and privates states are WeakMaps.

This basically involves having a local WeakMap in scope of your prototype

Disclaimer: WeakMaps are ES6 , I belief currently only firefox 6 has an implementation, However they can be shimmed

var Message = (function() {
    var map = new WeakMap();

    var Message = function(div) {
        var privates = {};
        map.set(this, privates);
        privates.div = document.getElementById(div);
    };

    Message.prototype.messages = {
        name: 'Please enter a valid name',
        email: 'Please enter a valid email',
        pass: 'Please enter passoword, 6-40 characters',
        url: 'Pleae enter a valid url',
        title: 'Pleae enter a valid title',
        tweet: 'Please enter a valid tweet',
        empty: 'Please complete all fields',
        same: 'Please make emails equal',
        taken: 'Sorry, that email is taken',
        validate: 'Please contact <a class="d" href="mailto:support@host.com">support</a> to reset your password'
    };

    Message.prototype.display = function(type) {
        var privates = map.get(this);
        Control.sendInner(privates.div, this.messages[type]);
    };

    return Message;
}());

Note that WeakMaps are ES6 and that there is a significantly computational overhead to get objects from a weakmap rather then from this.

I have an article about emulating WeakMaps - Prototypes and privates state

Using the klass utility mentioned in the article the code would look like:

var Message = klass(function(privates) {
    return {
        constructor: function(div) {
            privates(this).div = document.getElementById(div);
        },
        messages: {
            name: 'Please enter a valid name',
            email: 'Please enter a valid email',
            pass: 'Please enter passoword, 6-40 characters',
            url: 'Pleae enter a valid url',
            title: 'Pleae enter a valid title',
            tweet: 'Please enter a valid tweet',
            empty: 'Please complete all fields',
            same: 'Please make emails equal',
            taken: 'Sorry, that email is taken',
            validate: 'Please contact <a class="d" href="mailto:support@host.com">support</a> to reset your password'
        },
        display = function(type) {
            Control.sendInner(privates(this).div, this.messages[type]);
        }
    };
});

Again using privates(this).x instead of this.x has a computational overhead of two function calls. this should not be ignored.

Also note that using weakmaps has significantly less memory overhead then using closures since your still using prototypes for functions and only using weakmaps for state.

Is the cost worth it? Is the extra run time worth the privacy?

Personally I say run-time penalty for 'privacy' is something that needs to be benchmarked. The overhead computationally is small and the overhead in memory usage is also small.

Answer 2

So, the form I use is this:

var Message = function (div) {
    this.div = document.getElementById(div);
    // messages will be 'private'
    var messages = { 'name' : 'Please enter ...' }; // You get the picture here

    this.display = function (type) {
        Control.sendInner(this.div, messages);
    }
}

You can read more about private, static and public variables in this post under the Object Scope header.

Update: You can also use Strict Mode and set non-writable variables, or a getter only value. Though, this is not well supported as you might hope, and will probably cause you to be a lot stricter in how you write your code.

Answer 3

In your constructor any variable you declare within that function is effectively private - it's scoped to that instance only, i.e.:

var Message = function( div ) 
{
    var private = "hello, world!";
    this.div = document.getElementById( div ); 
};

However, these variables are so private that they can't be accessed from functions that you subsequently add to the prototype.

The only way to access them is via so-called "privileged methods", i.e. ones created as properties of this inside the object.

Answer 4

I don't believe any kind of privacy is possible in JavaScript except via using scoping rules for variables. This doesn't always mean an immediately-invoked function expression, though. You can use constructor-scoped variables combined with constructor-assigned methods, like this:

function YourConstructor() {
    var private1 = 0,
        private2 = 'spock';

    this.count = function () { return private1++; }    
    this.chiefOfficer = function (name) { 
       if(name) private2 = name;
       return private2; 
    }
}

and even if you execute code before YourConstructor is defined, there's forward declaration magic that takes place and everything's fine (note: some of the other solutions posted use the var YourConstructor = function () {... idiom -- these won't work in situations where forward declaration is required).

There's one issue with this: you're defining your constructor-assigned methods every time you invoke your constructor (rather than once in assignation to the prototype). There may be a performance/memory hit for cases where you're creating a lot of these objects.

A word about privacy, though: I'd invite you to consider the opinion that most of the time, the need for privacy via a runtime-enforced mechanism is overrated.

Why? Developers have a lot to do; in all likelihood, they'd probably rather not have to pay attention to the internals of any given abstraction unless it leaks something noxious.

Classes that don't cause problems, that throw/return useful errors, that provide genuinely useful methods that you can call to get things done (vs lots of getters and setters!), and are documented well enough... these kind of classes probably won't need any kind of privacy enforcement mechanism because everyone will be so happy with the work your classes are saving them they won't ever peer inside.

For classes that don't meet that standard, the lack of a privacy enforcement mechanism may not be the real problem.

There is an exception to this: sometimes (particularly on a mashable web) you have code from untrusted sources mingling with yours. In a very dynamic language (like JavaScript), you may want to isolate/hide certain functionality in places where outside code can't get to it. If you're not worrying about this, though, you may want to spend more time encouraging implementation hiding/privacy socially via good design and documentation, less worrying about technical enforcement.