Private Variables in JavaScript

Because JavaScript uses prototype-based inheritance, there is no keyword to define a member as “private” or “protected”. Either the object has a member, or it doesn’t, and you can access that member from anywhere you can access the object. Do not despair! There is a way to implement private variables… using another feature of the language: closures!

Closures

Closures are fairly simple, but frequently misunderstood. What you need to know for now, is that a closure allows you to reference an outer variable from within a function, even when the function is called from another context.

Another important aspect of closures, is that a new one is created with every function definition, even when that function definition is nested. Here is an illustration of that.

function countup(){var count =0;// private variable, only accessible within this functionreturnfunction iterate(){// return newly defined functionreturn++count;// referencing variable from outer scope}};var iterate1 = countup();// every time countup() is called...var iterate2 = countup();// a new private variable "count" is created// a new private function called "iterate" is defined// which causes a new closure to be created with that// new private function, and its environment
iterate1();// 1
iterate1();// 2
iterate2();// 1 // points to a different closure, with a different internal "count" variable
iterate2();// 2

You can probably see where this is going.

Private Members

Using this knowledge, you can probably already see how to create variables that are not accessible from outside of an object, but can be used by the methods of that object. These private members can be variables or functions.

There are a few different ways to accomplish this. Above is probably the most simple. If you have ever written (or read the source code for) a jQuery plugin, you have probably seen something like this:

2 Responses to “Private Variables in JavaScript”

The revealing module pattern is good for a lot of things, but you need to be a little more careful with your inheritance. If you override any of the “revealed” members, you get potentially inconsistent behavior, since all of the private members are still pointed at the original members, not the overridden ones.

Other than that, I agree. The revealing module pattern is a little easier to read.