Question

This SO-question kept bugging me. It’s a question that seems to reappear on a regular basis in SO.

Now I’ve deviced a way to create a constructor function trying to manage that private ‘properties’ can only be set from the constructors prototype get/set methods, using a private storage. In it’s basic form it looks like this:

The basic constructor function:

function Human(){
   /** set up a property storage **/   
   var storage = {
      name: { val: name || '-', get:true, set:true }
      ,age: { val: (age || '0'), get:true, set:true }
   };
   function get(){
       if (get.caller !== Human.prototype.get &&
           get.caller !== Human.prototype.set ){ return null }
       return storage;
   }
   this._get = get;
}

Adding get/set prototype methods to Human

Human.prototype = {
     get: function(prop){
        return this._get()[prop];
     }
    ,set: function(prop, val){
       var storage = this._get();
       /** 
              set functionallity, returning 
              the current object after setting
              see jsfiddle link @ the bottom of
              this question
        **/
       return this;
    }
};
// usage
var pete = new Human('Pete',23);
pete.get('name'); //=> 'Pete'
pete.set('name','Pete Justin');
pete.get('name'); => 'Pete Justin'
// but
pete.name; //=> 'undefined'

I am really interested in your comments. Maybe I am thinking in a completely wrong direction, maybe you say it’s an unnecessary operation, violating the prototypal nature of js, it already has been done (and better) elsewhere, or anything. Please tell me!

What I think of this – well here let’s call it – pattern: what you loose using it is the ease of simply declaring and getting properties (this.some = that etc.), what you win is better encapsulation, privacy of instance variables and some control over the properties you use (not sure if it’s the right terminology, but then again in the OOP world it sometimes looks like everyone gives it’s own private meaning to terminology).

Anyway, I’ve cooked a more complete and working Human in this jsfiddle.

• [edit1] In response to comment: ditched the immediately invoke function (iif)
• [edit2] Less private alternative without .caller, but still able to use the private storage: see this jsfiddle
• [edit3] Might as well ditch the prototype too
• [edit4] To be complete: here’s a genuine prototypal get/set variant

Answer 1

First of all what is this overly engineered solution trying to solve?

The problem with trying to access constructor local variables from the prototype is not a problem. People either need to only use the prototype and store all the data on this for a minor speed gain or not complain about creating extra functions for each object (minimal overhead). It’s a common misunderstanding that creating extra functions for each object is expensive.

---

No offence but the code is over engineered, complex and seems like a right pain to read or maintain. I don’t see any advantages in this method? Why not just make this._store a privileged function.

Also the fact that you have a local function in your constructor means you lose that advantage with the prototype of having one function for all objects. I’ve also over engineered a solution similar to this to “emulate” private variables, the code became a right mess to work with and I had to abandon it.

---

As for code critism:

.caller is non standard. You can’t use it. It’s a hack.

this._store = {get:get};

Why not just this._store = get ?

This

function thisget(prop){
    return storage[prop];
}
return thisget(prop);

should be inlined to

return storage[prop]