Encapsulation in OOP JavaScript

Encapsulation is a useful technique in programming which allows you to separate an abstraction's implementation from its interface, thus enabling future changes to the implementation without affecting the interface. There are other benefits of encapsulation, such as:

• Being able to screen (validate) new properties, via setter methods.
• Being able to process properties before their "release", via getter methods.
• Making your abstraction less prone to abuse by other developers - specifically, to protect private variables and states that could compromise the effectiveness of the abstraction.

Grady Booch (author of "Object Oriented Analysis and Design") describes encapsulation as:

"The process of compartmentalizing the elements of an abstraction that constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation."

JavaScript is often considered a toy that doesn't know of complex design patterns or have the capacity to support techniques such as encapsulation, but, contrary to misinformed belief, JavaScript does have capacity for encapsulation. It's just quite tricky, that's all!

Hiding your variables in closures

It's possible to hide variables in JavaScript. To make this happen we take advantage of the closure:

function Person(name, age) {

 
    this.toString = function() {
        return 'Name: ' + name + ', Age: ' + age;

    };
 
}

If you're not sure what a closure is just think of it as a function defined within another function. The "child" function has access to the "parent" function's scope.

You can see that we're defining the toString method within the constructor.

The only reason to define a constructor's methods anywhere other than its prototype, is in the situation where that method needs access to variables defined in the constructor's scope. Above, the toString method needs access to the variables, name and age.

Setters (and getters)

Once we instantiate this constructor (new Person('Jim', 88);), there's no way to change the name or age - they're "hard-coded" in the inaccessible "parent" scope.

We can make it possible to change these values by adding a couple of setter (AKA, mutator) methods:

function Person(name, age) {

 
    this.toString = function() {
        return 'Name: ' + name + ', Age: ' + age;

    };
 
    this.setName = function(newName) {

        name = newName;
    };
 
    this.setAge = function(newAge) {

        age = newAge;
    };
 
}
 
var jimmy = new Person('Jim', 88);

 
jimmy.toString(); // => "Name: Jim, Age: 88"
 
jimmy.setName('Jimmy');

 
jimmy.toString(); // => "Name: Jimmy, Age: 88"

This works perfectly, although there are a couple of points to discuss.

First, defining a bunch of methods in the constructor takes quite a bit of room and with a few more setter methods (and getters) the constructor can easily transform into a hard-to-read and hard-to-maintain piece of code. Semantically, this solution fails - a constructor should only contain what's needed to create an instance - ideally, this shouldn't include a bunch of method definitions.

Secondly, it's slow. Redefining a bunch of functions upon every single instantiation isn't going to be as fast as keeping all the methods in the prototype.

So, either we reach a compromise or we forget about real encapsulation, and settle for something a little less secure. For example, we could define all the getters and setters in the prototype and store our "privates" as public properties, but prefix them with an underscore or some other symbol to signify their private nature:

function Person(name, age) {

 
    this._name = name;
    this._age = age;

 
}
 
Person.prototype.toString = function() {

    return 'Name: ' + this._name + ', Age: ' + this._age;

};
 
Person.prototype.setName = function(newName) {

    this._name = newName;
};
 
Person.prototype.setAge = function(newAge) {

    this._age = newAge;
};

Our constructor is now a lot simpler and the setters work as required. The only issue with this approach is that there's no real information-hiding going on. Developers using the abstraction can still access the "implementation" (the private state).

Real encapsulation, the hard way

For real encapsulation, the following criteria need to be met:

• You must be able to define private properties within the constructor and methods.
• You must be able to access and manipulate the private properties within the constructor and methods.
• The private properties must not be directly accessible from outside (i.e. as properties on the instance).

To fulfill these criteria we're going to need to create a small abstraction that will enable us to define our constructor, its methods, and its properties in a plain object, which will then be processed to produce the required constructor and prototype.

In accordance with convention, this abstraction will be named Class. This is how it will typically work:

var Person = new Class({

 
    _name: 'Blank',
    _age: 0,
 
    init: function(name, age) {

        this.name = name;
        this.age = age;

    },
 
    toString: function() {
        return 'Name: ' + this.name + ', Age: ' + this.age;

    },
 
    setAge: function(age) {
        this.age = age;

    },
 
    setName: function(name) {
        this.name = name;

    }
 
});

The underscore prefix tells Class that we want those properties to be private. Privacy is achieved by retaining a truly private (in a closure) privates array, each item within the array represents the private properties of each instance. This will be clearer once you've seen the source (below).

Class looks for an init method to use as the constructor.

Here's the source for Class, excluding the function:

function Class(o){
 
    var id = 0,

        privates = {},
        instancePrivates = [],
        constructor = function(){

 
            this.__id = id++;
 
            // Copy privates over to new privates obj,
            // just for this instance.
            instancePrivates[this.__id] = {

                privates: merge({}, privates),
                constructor: this

            };
 
            if (this.init) {
                this.init.apply(this, arguments);

            }
 
            return this;
 
        },
        m;

 
    function method(name, fn) {
 
        constructor.prototype[name] = function() {

 
            var i, ret,
                thisPrivates = instancePrivates[this.__id] || {};

 
            // Check constructor
            if (thisPrivates.constructor !== this) {

                // this.__id has been changed, exit.
                return;
            }
 
            thisPrivates = thisPrivates.privates;

 
            for (i in thisPrivates) {
                this[i] = thisPrivates[i];

            }
 
            ret = fn.apply(this, arguments);

 
            for (i in thisPrivates) {
                thisPrivates[i] = this[i];

                delete this[i];
            }
 
            return ret;

 
        };
 
    };
 
    for (m in o) {

 
        // Test for privates
        if ( /^_/.test(m) ) {

 
            privates[m.replace(/^_/, '')] = o[m];

 
        } else {
 
            method(m, o[m]);

 
        }
 
    }
 
    return constructor;
 
}

There are cleaner ways of implementing this, but just for readability's sake, we're identifying each instance with a simple __id property. Yes, this can be manipulated from the outside, but doing so would result in the methods not running.

It has some constraints, but it does provide us with encapsulation:

var Person = new Class({

 
    _name: 'Blank',
    _age: 0,
 
    init: function(name, age) {

        this.name = name;
        this.age = age;

    },
 
    toString: function() {
        return 'Name: ' + this.name + ', Age: ' + this.age;

    },
 
    setAge: function(age) {
        this.age = age;

    },
 
    setName: function(name) {
        this.name = name;

    }
 
});
 
// Testing:
 
var jimmy = new Person('Jim', 88);

 
jimmy._name; // undefined
jimmy.name; // undefined
 
jimmy.toString(); // => "Name: Jim, Age: 88"

 
jimmy.setName('Jimmy');
jimmy.toString(); // => "Name: Jimmy, Age: 88"

 
jimmy.setAge(54);
jimmy.toString(); // => "Name: Jimmy, Age: 54"

 
jimmy._age; // undefined
jimmy.age; // undefined

You can also have private methods, e.g.

var Box = new Class({
 
    _width: 0,

    _height: 0,
 
    init: function(width, height) {

        this.width = width;
        this.height = height;

    },
 
    info: function() {
        return 'Width: ' + this.width +

                ',\nHeight: ' + this.height +
                ',\nArea: ' + this.calcArea();

    },
 
    _calcArea: function() {
        return this.width * this.height;

    }
 
});
 
var myBox = new Box(100, 100);

 
myBox.calcArea; // undefined
myBox._calcArea; // undefined
 
myBox.info(); // => "Width: 100,\nHeight: 100,\nArea: 10000"

Conclusion

The method I used to achieve full encapsulation, while quite novel, isn't going to be appropriate in all situations. The population and clearing of private variables has to happen on every method call, and so will likely cause a significant overhead in some applications.

That said, I don't think the overhead will be all that significant, unless you've got a crazy amount of private properties/methods.

I hope this post has given you some insight into how you can achieve encapsulation and information-hiding in JavaScript.