Closures vs. classes for encapsulation?

Question

I'm new to JS (from C++/etc), and it's just occurred to me that closures seem to be a simpler and more convenient way to handle encapsulation than classes. This code seems to give a simple way to handle encapsulation:

function addProperty(o) {
   var value;

   o["get"] = function()  { return value; }
   o["set"] = function(v) { value = v; }
}

// create two independent objects which are instances of pseudo-class 'addProperty',
// which each have their own version of a set of local fields, and methods that
// operate on those fields:
var a = {};
addProperty(a);
var b = {};
addProperty(b);

If you just want a class to handle encapsulation (in C++, I find this is most of the time), is there any good reason to use a JS class instead of a closure? The code above seems to me to be more intuitive and compact than JS classes. No constructors, prototypes, or excessive use of 'this'. You also get the benefit that you must explicitly declare local fields, instead of hoping that you don't make any typos in your constructor.

EDIT

Ok, I'll just clarify. Seems like the 'class' word gets some backs up. A "class", to me anyway, is an extension of the type concept, and JS doesn't qualify on that front, but I can do various class-y things with what my book (Flanagan) spends 50 pages calling classes. Sort of.

Anyway, the real question is this: I'm using jQuery tabs on my first web app. I noticed yesterday that this doesn't work, because my JS code doesn't keep any private state for each tab. When I swap between tabs, the dynamic/mouse parts of my code no longer work properly.

So, what's the best way to introduce private state into the app? Most of the code is safe, but everything that handles dynamic behaviour needs some way to encapsulate per-tab local state. With a C++ background, the obvious answer to me is to write a class that defines the dynamic parts of a tab, and to instantiate a new 'tab' object each time a tab is created. What I'm finding it difficult to get my head around is whether JS pseudo-classes actually make any sense here, or whether I should extend the code above.

Just read the module patterns link from Jonathan, and it now seems to me to be that that may be the answer.

Thanks.

Answer 1

This is an old question, but there are a few things the answers are missing so I figure I'd add to this.

First, as commenters love to point out, there aren't any real classes in javascripts, we just mimic them with closures. Here's what the javascript tutorials call a "class:"

function Class1(){
    var privateState='blah';
    this.get=function(){
        return privateState;
    }
}
var myObj=new Class1();

Importantly, the get method is just a closure. So, this is basically the same as your code. Because closures must reference the environment in which they were created (this is how they can use the private internal state data), they are more costly than just using a public function. So if you have a static method that doesn't require the internal state, you should add it to Class1 instead by using the prototype key word:

Class1.prototype.staticMethod=function(){...};

This way, the static method can be used through the prototype chain without using up extra memory with unnecessary closures. You could also achieve this with your method by adding static methods outside of your AddPropertyfunction.

So, in the end the only difference between a formal javascript "class" and your AddProperty function is that when you actually use the class constructor, the class appears in the object's prototype chain, whereas your objects just inherit directly from the generic object prototype. You could certainly write code that uses this distinction, but that would probably be bad code.

Answer 2

The benefit of a function for the purposes of encapsulating functionality is that you can use the module pattern:

http://www.adequatelygood.com/2010/3/JavaScript-Module-Pattern-In-Depth

The module pattern provides the capability of creating private members and methods, without something with a lot of overhead like ease.js:

http://easejs.org/

Answer 3

The reasons to avoid closures is overhead.

Your get and set functions are trivially 20x slower than properties. Your closures also have a large memory overhead that is O(N) with the number of instances.

Also note that these encapsulated variables have zero real benefit, they just infer performance penalties.

var AddProperty = {
  constructor: function (v) { this._value = v; return this; },
  get: function () { return this._value; },
  set: function (v) { this._value = v; }
};

var a = Object.create(AddProperty).constructor(1);
var b = Object.create(AddProperty).constructor(2);

I noticed yesterday that this doesn't work, because my JS code doesn't keep any private state for each tab.

Your problem is not that you don't have private state, it's that you're using global state.

The easy solution is to have an object per tab (or a "struct" if you prefer) and store state in it.

So all you have to do is define a tab

var Tab = {
  constructor: function (...) {
    /* init state */
  },
  doTabStuff: function () { /* some method */ },
  ...
}

And then create new tabs when you need them

var tab = Object.create(Tab).constructor(...)