javascript - accessing private member variables from prototype-defined functions

0 votes
asked Jan 12, 2009 by morgancodes

Is there any way to make "private" variables (those defined in the constructor), available to prototype-defined methods?

TestClass = function(){
    var privateField = "hello";
    this.nonProtoHello = function(){alert(privateField)};
TestClass.prototype.prototypeHello = function(){alert(privateField)};

This works:


but this doesn't:


I'm used to defining my methods inside the constructor, but am moving away from that for a couple reasons.

Thanks sktrdie,

That works, it would be nice not to have to create the this.accessPrivateField. If my "hello" function is defined inside the constructor, privateField is in the scope chain of the function, so I can treat privateField as I would a private field in java. It's a little more cumbersome to set up accessors (this.accessPrivateField), and then, privateField isn't really private any more.

I know javascript isn't java, but I like java!

22 Answers

0 votes
answered Jan 12, 2009 by triptych

No, there's no way to do it. That would essentially be scoping in reverse.

Methods defined inside the constructor have access to private variables because all functions have access to the scope in which they were defined.

Methods defined on a prototype are not defined within the scope of the constructor, and will not have access to the constructor's local variables.

You can still have private variables, but if you want methods defined on the prototype to have access to them, you should define getters and setters on the this object, which the prototype methods (along with everything else) will have access to. For example:

function Person(name, secret) {
    // public = name;

    // private
    var secret = secret;

    // public methods have access to private members
    this.setSecret = function(s) {
        secret = s;

    this.getSecret = function() {
        return secret;

// Must use getters/setters 
Person.prototype.spillSecret = function() { alert(this.getSecret()); };
0 votes
answered Jan 12, 2009 by jason-s

see Doug Crockford's page on this. You have to do it indirectly with something that can access the scope of the private variable.

another example:

Incrementer = function(init) {
  var counter = init || 0;  // "counter" is a private variable
  this._increment = function() { return counter++; }
  this._set = function(x) { counter = x; }
Incrementer.prototype.increment = function() { return this._increment(); }
Incrementer.prototype.set = function(x) { return this._set(x); }

use case:

js>i = new Incrementer(100);
[object Object]
0 votes
answered Jan 24, 2009 by angelscrimes

You can use a prototype assignment within the constructor definition.

The variable will be visible to the prototype added method but all the instances of the functions will access the same SHARED variable.

function A()
  var sharedVar = 0;
  this.local = "";

  A.prototype.increment = function(lval)
    if (lval) this.local = lval;    
    alert((++sharedVar) + " while this.p is still " + this.local);

var a = new A();
var b = new A();    
a.increment("I belong to a");
b.increment("I belong to b");

I hope this can be usefull.

0 votes
answered Jan 26, 2010 by lance-ewing

I suggest it would probably be a good idea to describe "having a prototype assignment in a constructor" as a Javascript anti-pattern. Think about it. It is way too risky.

What you're actually doing there on creation of the second object (i.e. b) is redefining that prototype function for all objects that use that prototype. This will effectively reset the value for object a in your example. It will work if you want a shared variable and if you happen to create all of the object instances up front, but it feels way too risky.

I found a bug in some Javascript I was working on recently that was due to this exact anti-pattern. It was trying to set a drag and drop handler on the particular object being created but was instead doing it for all instances. Not good.

Doug Crockford's solution is the best.

0 votes
answered Jan 13, 2012 by mims-h-wright

When I read this, it sounded like a tough challenge so I decided to figure out a way. What I came up with was CRAAAAZY but it totally works.

First, I tried defining the class in an immediate function so you'd have access to some of the private properties of that function. This works and allows you to get some private data, however, if you try to set the private data you'll soon find that all the objects will share the same value.

var SharedPrivateClass = (function(){ // use immediate function
    // our private data
    var private = "Default";

    // create the constructor
    function SharedPrivateClass () {}

    // add to the prototype
    SharedPrivateClass.prototype.getPrivate = function () {
        // It has access to private vars from the immediate function!
        return private;

    SharedPrivateClass.prototype.setPrivate = function (value) {
        private = value;

    return SharedPrivateClass;

var a = new SharedPrivateClass();
console.log("a:", a.getPrivate()); // "a: Default"

var b = new SharedPrivateClass();
console.log("b:", b.getPrivate()); // "b: Default"

a.setPrivate("foo"); // a Sets private to 'foo'
console.log("a:", a.getPrivate()); // "a: foo"
console.log("b:", b.getPrivate()); // oh no, b.getPrivate() is 'foo'!

console.log(a.hasOwnProperty("getPrivate")); // false. belongs to the prototype
console.log(a.private); // undefined

There are plenty of cases where this would be adequate like if you wanted to have constant values like event names that get shared between instances. But essentially, they act like private static variables.

If you absolutely need access to variables in a private namespace from within your methods defined on the prototype, you can try this pattern.

var PrivateNamespaceClass = (function(){  // immediate function
    var instance = 0, // counts the number of instances
        defaultName = "Default Name",  
        p = []; // an array of private objects

    // careate the constructor
    function PrivateNamespaceClass () {
        // Increment the instance count and save it to the instance. 
        // This will become your key to your private space.
        this.i = instance++; 

        // Create a new object in the private space.
        p[this.i] = {};
        // Define properties or methods in the private space.
        p[this.i].name = defaultName;

        console.log("New instance " + this.i);        
    PrivateNamespaceClass.prototype.getPrivateName = function () {
        // It has access to the private space and it's children!
        return p[this.i].name;
    PrivateNamespaceClass.prototype.setPrivateName = function (value) {
        // Because you use the instance number assigned to the object (this.i)
        // as a key, the values set will not change in other instances.
        p[this.i].name = value;
        return "Set " + p[this.i].name;

    return PrivateNamespaceClass;

var a = new PrivateNamespaceClass();
console.log(a.getPrivateName()); // Default Name

var b = new PrivateNamespaceClass();
console.log(b.getPrivateName()); // Default Name

console.log(a.getPrivateName()); // A
console.log(b.getPrivateName()); // B

console.log(a.privateNamespace); // undefined

I'd love some feedback from anyone who sees an error with this way of doing it.

0 votes
answered Jan 24, 2012 by tim


That won't work. If you do

var t2 = new TestClass();

then t2.prototypeHello will be accessing t's private section.


The sample code works fine, but it actually creates a "static" private member shared by all instances. It may not be the solution morgancodes looked for.

So far I haven't found an easy and clean way to do this without introducing a private hash and extra cleanup functions. A private member function can be simulated to certain extent:

(function() {
    function Foo() { ... } = function() {, blah);
    function privateFoo(blah) { 
        // scoped to the instance by passing this to call 

    window.Foo = Foo;
0 votes
answered Jan 7, 2013 by chris-west

You can actually achieve this by using Accessor Verification:

(function(key, global) {
  // Creates a private data accessor function.
  function _(pData) {
    return function(aKey) {
      return aKey === key && pData;

  // Private data accessor verifier.  Verifies by making sure that the string
  // version of the function looks normal and that the toString function hasn't
  // been modified.  NOTE:  Verification can be duped if the rogue code replaces
  // Function.prototype.toString before this closure executes.
  function $(me) {
    if(me._ + '' == _asString && me._.toString === _toString) {
      return me._(key);
  var _asString = _({}) + '', _toString = _.toString;

  // Creates a Person class.
  var PersonPrototype = (global.Person = function(firstName, lastName) {
    this._ = _({
      firstName : firstName,
      lastName : lastName
  PersonPrototype.getName = function() {
    var pData = $(this);
    return pData.firstName + ' ' + pData.lastName;
  PersonPrototype.setFirstName = function(firstName) {
    var pData = $(this);
    pData.firstName = firstName;
    return this;
  PersonPrototype.setLastName = function(lastName) {
    var pData = $(this);
    pData.lastName = lastName;
    return this;
})({}, this);

var chris = new Person('Chris', 'West');

This example comes from my post about Prototypal Functions & Private Data and is explained in more detail there.

0 votes
answered Jan 19, 2013 by edward

Yes, it's possible. PPF design pattern just solves this.

PPF stands for Private Prototype Functions. Basic PPF solves these issues:

  1. Prototype functions get access to private instance data.
  2. Prototype functions can be made private.

For the first, just:

  1. Put all private instance variables you want to be accessible from prototype functions inside a separate data container, and
  2. Pass a reference to the data container to all prototype functions as a parameter.

It's that simple. For example:

// Helper class to store private data.
function Data() {};

// Object constructor
function Point(x, y)
  // container for private vars: all private vars go here
  // we want x, y be changeable via methods only
  var data = new Data;
  data.x = x;
  data.y = y;


// Prototype functions now have access to private instance data
Point.prototype.getX = function(data)
  return data.x;

Point.prototype.getY = function(data)
  return data.y;


Read the full story here:

PPF Design Pattern

0 votes
answered Jan 3, 2014 by scott-rippey

Update: With ES6, there is a better way:

Long story short, you can use the new Symbol to create private fields.
Here's a great description:


var Person = (function() {
    // Only Person can access nameSymbol
    var nameSymbol = Symbol('name');

    function Person(name) {
        this[nameSymbol] = name;

    Person.prototype.getName = function() {
        return this[nameSymbol];

    return Person;

For all modern browsers with ES5:

You can use just Closures

The simplest way to construct objects is to avoid prototypal inheritance altogether. Just define the private variables and public functions within the closure, and all public methods will have private access to the variables.

Or you can use just Prototypes

In JavaScript, prototypal inheritance is primarily an optimization. It allows multiple instances to share prototype methods, rather than each instance having its own methods.
The drawback is that this is the only thing that's different each time a prototypal function is called.
Therefore, any private fields must be accessible through this, which means they're going to be public. So we just stick to naming conventions for _private fields.

Don't bother mixing Closures with Prototypes

I think you shouldn't mix closure variables with prototype methods. You should use one or the other.

When you use a closure to access a private variable, prototype methods cannot access the variable. So, you have to expose the closure onto this, which means that you're exposing it publicly one way or another. There's very little to gain with this approach.

Which do I choose?

For really simple objects, just use a plain object with closures.

If you need prototypal inheritance -- for inheritance, performance, etc. -- then stick with the "_private" naming convention, and don't bother with closures.

I don't understand why JS developers try SO hard to make fields truly private.

0 votes
answered Jan 16, 2014 by scott-rippey

In current JavaScript, I'm fairly certain that there is one and only one way to have private state, accessible from prototype functions, without adding anything public to this. The answer is to use the "weak map" pattern.

To sum it up: The Person class has a single weak map, where the keys are the instances of Person, and the values are plain objects that are used for private storage.

Here is a fully functional example: (play at

var Person = (function() {
    var _ = weakMap();
    // Now, _(this) returns an object, used for private storage.
    var Person = function(first, last) {
        // Assign private storage:
        _(this).firstName = first;
        _(this).lastName = last;
    Person.prototype = {
        fullName: function() {
            // Retrieve private storage:
            return _(this).firstName + _(this).lastName;
        firstName: function() {
            return _(this).firstName;
        destroy: function() {
            // Free up the private storage:
            _(this, true);
    return Person;

function weakMap() {
    var instances=[], values=[];
    return function(instance, destroy) {
        var index = instances.indexOf(instance);
        if (destroy) {
            // Delete the private state:
            instances.splice(index, 1);
            return values.splice(index, 1)[0];
        } else if (index === -1) {
            // Create the private state:
            return values[values.length - 1];
        } else {
            // Return the private state:
            return values[index];

Like I said, this is really the only way to achieve all 3 parts.

There are two caveats, however. First, this costs performance -- every time you access the private data, it's an O(n) operation, where n is the number of instances. So you won't want to do this if you have a large number of instances. Second, when you're done with an instance, you must call destroy; otherwise, the instance and the data will not be garbage collected, and you'll end up with a memory leak.

And that's why my original answer, "You shouldn't", is something I'd like to stick to.

Welcome to Q&A, where you can ask questions and receive answers from other members of the community.
Website Online Counter