Object Oriented Programming in JavaScript

by Mike Koss
January 14, 2006


The first version of this paper, written in 2003, had several shortcomings, not the least of which was that the techniques described were specific to Internet Explorer. I've updated and improved on the original, to document the current state of the art, especially in light of the extensive interest in AJAX technology and the increasing adoption of the FireFox browser. All the examples presented here will follow the ECMA language standards and can be applied to Internet Explorer, FireFox, and ActionScript (in Macromedia Flash).

While early adopters of JavaScript used it as a simple scripting engine to create dynamic web pages, modern web designers have come to use more sophisticated object oriented techniques in building their code. I will present here, both the common paradigms used in object oriented JavaScript programming, and also suggest some helper functions that you can use in your code to streamline the process.

It should be noted that the current design of the JavaScript language, did not fully anticipate or fully implement an object oriented system. That is why the subject is somewhat mysterious and there are various implementations of object oriented programming techniques being used on the web today. I will describe what I believe to be the most main-stream and compatible implementation that fits most naturally into the design of the language.

Object Oriented Programming Goals

I assume that the reader has a basic familiarity with JavaScript, function calls, and the basic tenets of object oriented programming. I consider the three primary goals of object oriented programming to be:

Through a series of examples (which, for the curious reader, are actually snippets of live JavaScript code embedded within this page), I will demonstrate how objects can be used in JavaScript and how these object oriented paradigms can be best implemented. I will cover techniques for:

Simple Objects

Doug Crockford's book explains of the best parts of the JavaScript language.
-- Mike Koss

The simplest object oriented construct in JavaScript is the built-in Object data type. In JavaScript, objects are implemented as a collection of named properties. Being an interpreted language, JavaScript allows for the creation of any number of properties in an object at any time (unlike C++, properties can be added to an object at any time; they do not have to be pre-defined in an object declaration or constructor).

So, for example, we can create a new object and add several ad-hoc properties to it with the following code:

Which creates a JavaScript object which I will represent graphically like this:

The left hand column displays the property name of each available property on the object, while the right hand column displays it's value. Note that in addition to the x and y properties that we created, our object has an additional property called constructor that points (in this case) to an internal JavaScript function. I will explain prototype properties, below.

Defining a Class - Object Constructors

A new JavaScript class is defined by creating a simple function. When a function is called with the new operator, the function serves as the constructor for that class. Internally, JavaScript creates an Object, and then calls the constructor function. Inside the constructor, the variable this is initialized to point to the just created Object. This code snippet defines a new class, Foo, and then creates a single object of that class.

Note that we can now create as many Foo type objects as we want, all of whom will be properly initialized to have their x and y properties set to 1 and 2, respectively.

Prototypes Explained

In JavaScript, each Object can inherit properties from another object, called it's prototype. When evaluating an expression to retrieve a property, JavaScript first looks to see if the property is defined directly in the object. If it is not, it then looks at the object's prototype to see if the property is defined there. This continues up the prototype chain until reaching the root prototype. Each object is associated with a prototype which comes from the constructor function from which it is created.

For example, if we want to create an object, X, from constructor function B, whose prototype chain is: B.prototype, A.prototype, Object.prototype:

We would use the following code:

In FireFox and in ActionScript, an object's prototype can be explicitly referenced via the non-standard __proto__ property. But in standard JavaScript a prototype object can only by directly referenced through the object's constructor function object.

Defining and Calling Methods in a Class

JavaScript allows you to assign any function to a property of an object. When you call that function using obj.Function() syntax, it will execute the function with this defined as a reference to the object (just as it was in the constructor).

The standard paradigm for defining methods is to assign functions to a constructor's prototype. That way, all objects created with the constructor automatically inherit the function references via the prototype chain.

Polymorphism is achieved by simply having different object classes implement a collection of methods that use the same names. Then, a caller, need just use the correctly named function property to invoke the appropriate function for each object type.

Defining a Sub-Class

The standard paradigm, is to use the prototype chain to implement the inheritance of methods from a super class. Any methods defined on the sub-class will supersede those defined on the super-class.

Something to keep in mind is that each time a sub-class is defined, we explicitly call the constructor of the super-class in order to insert it into our prototype chain. So it is important to ensure that no undesirable side-effects will occur when this call is made. Conversely, if the super-class constructor should be called for each instance of every sub-class, code must be explicitly added to the sub-class's constructor to make this call (as is done in the above example).

An Alternate Sub-Classing Paradigm

As an alternate to using the prototype chain, I've developed a method which avoids calling the constructor of a super class when each sub-class is defined. Three methods are added to the Function object:

Repeating the sub-classing example using this new paradigm:

Unfortunately, this technique does not allow for the use of the instanceof operator to test for membership of a super-class. But, we have the added benefit that we can derive from more than one super class (multiple inheritance).

Private Members

Amazingly, JavaScript also can support private members in an object. When the constructor is called, variables declared in the function scope of the constructor will actually persist beyond the lifetime of the construction function itself. To access these variables, you need only create local functions within the scope of the constructor.  They may reference local variables in the constructor.

I believe, however, that each instance of an object created in this way, has it's own copy of each local function.  The local copy of the function can maintain a copy of the local scope (a closure) of the constructor.  This would be rather inefficient for object classes that construct many instances.  Experiments with a single (shared) reference to a function reveal that they can only reference variables from a single instance of the class.  Since the benefits of using private members is rather limited in the context of JavaScript (which is already lacking any form of type safety), I would not recommend making extensive use of the private member paradigm.

Update (June 2009): I've developed a simple library for building JavaScript Namespaces (public domain source code) - for a description see my blog.

blog comments powered by Disqus


ECMA-262 (PDF) - ECMAScript Standard Documentation

JavaScript Closures - Detailed (if lengthy) explanation of JavaScript closures, along with efficiency concerns especially with the inability of the garbage collector to clean up function calls in the presence of possible closures.