Encapsulation / Data Hiding in Javascript?

Question

I would like to understand the concept of Encapsulation in JavaScript, and how to make my properties and methods public or private.

I'm playing around with this example:

    var person = function(newName, newAge) {

    // Private variables / properties
    var name = newName;
    var age = newAge;

    // Public methods
    this.getName = function() {
        return name;
    }

    // Private methods
    var getAge = function() {
        return age;
    }

    // Public method, has acces to private methods
    this.giveAge = function() {
        return getAge();
    }
}

var jack = new person("Jack", 30);

console.log(jack.name); // undefined
console.log(jack.getName); // Jack
console.log(jack.getAge()); // TypeError: jack.getAge is not a function
console.log(jack.getAge); // undefined
console.log(jack.giveAge()); // 30

So, variables var name and var age are private. To access them I use public methods by using .this reference. So anything that is var inside my function is private, and anything that's .this inside my object is visible outside.

I guess that's cause person is visible, so it exposes all of its properties.

Am I on the right track? Is this the right way to hide or expose your properties / methods?

And one more question, why does console.log(jack.getAge()); throws an error? And when referencing functions I "stored" in variables, should I put () at the end of that function, it works both ways, so I don't know what do use?

Thanks!

Answer 1

I guess that's cause person is visible, so it exposes all of its properties.

Correct.

Am I on the right track? Is this the right way to hide or expose your properties / methods?

If you want to do it, then yes, this is a fairly standard way to do it. There's at least one other way as of ES2015, but with (probably) more overhead.

And one more question, why does console.log(jack.getAge()); throws an error?

Because the jack object doesn't have a getAge property, so jack.getAge yields undefined, which isn't a function. There's a getAge variable inside the context that the giveAge closure has access to (along with age and name), but jack doesn't have a getAge property.

And when referencing functions I "stored" in variables, should I put () at the end of that function, it works both ways, so I don't know what do use?

No, it doesn't work both ways. jack.getName gets a reference to the function. jack.getName() calls the function and gets its return value.

I should note that there's no point to the getAge function. It's only accessible to closures defined within the person function, just like age and name are. So anything that would use getAge would just use age instead and avoid the function call.

---

Just for completeness, I'll note that many people don't worry about truly private properties in JavaScript, opting instead for "private by convention" — e.g., they use a naming convention (such names starting with _) to mean "don't touch these, they're private." That doesn't do anything to prevent people using them, of course, it just indicates that they shouldn't. Folks advocating this usually point out that in many languages with "true" private properties/fields (Java, C#), those properties/fields are accessible with only a small amount of effort via reflection. And so, the argument goes, just using a naming convention is "as private."

I'm not agreeing (nor particularly disagreeing) with that, it does require rather more work in Java or C# to access private properties than public ones. I'm just noting that the "private by convention" approach is quite common, and frequently "good enough."

Answer 2

I guess that's cause person is visible, so it exposes all of its properties.

not exactly. First of all, person is a regular function. it can perfectrly be called without the new-keyword, but the results will blow up your whole application.

To understand why, you should first understand what the new-keyword does behind the scenes. This would be an js-implementation:

function fakeNew(constructor, ...args){
    if(typeof constructor !== "function"){
        throw new TypeError(constructor + " is not a constructor");
    }

    //create a new Instance of the constructors prototype-property
    var instance = Object.create(constructor.prototype);

    //invoke the constructor with the scope set to the instance and the provided arguments
    var result = constructor.apply(instance, args);

    //check wether the returned value is an Object (and functions are considered as Objects)
    if(result === Object(result)){
        //then return the result-value in favor to the instance
        return result;
    }

    //otherwise return the instance
    return instance;
}

On the other hand, any function can also be a constructor; no special needs, it's all up to you.

So back to jack

var jack = person("Jack", 30);  //would result in the following desaster:
console.log(jack);      //undefined, since person doesn't return anthing

console.log(jack.getName());    
//will throw, since jack is still undefined, and therefore doesn't have any properties

//BUT:
console.log(window.getName())   //will return "Jack" now

console.log(window.getAge);     //undefined, but this is fine 
//global scope has not been polluted with this one, cause getAge was a local variable inside the function-call

console.log(window.giveAge())   //can still call the enclosed (private) function getAge()

then

var jill = person("Jill", 28);
//will overwrite the global functions and expose new values now
console.log(window.getName(), window.giveAge()) //"Jill", 28    
//and Jack is kind of gone, well the variable is left but the variable contained undefined, so...

next thing is scoping. let's assume you made this correct

//first let's add a function that executes on the scope
//inside the constructor
this.getNameAndAge = function(){
    return this.getName() + ": " + getAge();
}

.

var andy = new person("Andy", 45);
var joe = new person("Joe", 32);

//let's make Andy a little younger
andy.getNameAndAge = joe.getNameAndAge;
console.log(andy.getNameAndAge(), andy.getName() + ": " + andy.giveAge());
//will result in "Andy: 32", "Andy": 45

waaaaat?

well you've overridden the public method getNameAndAge.
the name is accessed by invoking the (also public) method getName() on the current Object.
but giveAge() still the enclosed variable from the scope where this specific "instance of the getNameAndAge-function" was declared, and therefore it's from Joe's function call.

To understand the impacts of this, let's make the scoping even more weird

funciton Animal(species, _name){
    //species is likewise a local variable and can be enclosed, modified, or whatever
    //we don't need to write it to some different variable

    //but we want to expose the name of this animal, since it should be possible to change it later
    //without the need to create a getter and a setter just to change the property of _name
    this.name = _name;

    this.whoAreYou = function(){
        //so we concat the enclosed value from species with the name-argument on this object
        //in the hope that everything will be alright.
        return species + " " + this.name;
    }
}

var jack = new Animal("dog", "Jack");
var jill = new Animal("cat", "Jill");
var joe = new Animal("fish", "Joe");

console.log(jack.whoAreYou());  //"dog Jack"
console.log(jill.whoAreYou());  //"cat Jill"
console.log(joe.whoAreYou());   //"fish Joe"

//as far so good; till now ...
//since these properties are still writable someone will start and move them around

//maybe like a callback
function someFunction(someArg, callback){
    console.log(someArg, callback());
}
someFunction("Who are you?", jack.whoAreYou);

//or sth. like this:
//you may not believe that someone would ever do that, but it will happen!
jack.whoAreYou = jill.whoAreYou;
console.log(jack.whoAreYou());

//and now the poor dog has an Identity-crisis.
//the first one will result in:
"Who are you?", "dog undefined"

//the latter will log "cat Jack"

or even more fummy if sth. like this happens:

var fn = joe.whoAreYou;
console.log(fn.call(jack), fn.call(jill), fn.call(joe), fn.call(Animal));
//cause now they are all fishes, even the Animal-constuctor

I don't want to say that this is bad, or that you should avoid it but there is the way that it works, and that should be considered.

cause this way provides us with prototypal inheritance, and a great way to write mixins, without writing wrapper-methods all the time.

You can look at that as "i need to secure my private state", or "I work in whatever enviorment you provide to me"

And one more question, why does console.log(jack.getAge()); throws an error?

because jack.getAge is undefined and undefined is no function

var getAge = function() {
    return age;
}

another comment to this line

in JS function- and variable-declarations are hoisted and therefore available from the beginning of the function. Expressions are not.

var person = function(){
    //...
    foo();
    bar();
    baz();

    function foo(){ console.log("this will work"); }
    var bar = function(){ console.log("this will fail"); }
    //because to this point, bar was delared and assigned with undefined, 
    //and we remember? undefined can't be invoked

    return whatever;

    function baz(){ console.log("event this would work"); }
    //unless some preprocessor decided (falsely), that this function can be removed 
    //since it is after the return-statement, and is therefore unreachable
}