If you think you know how Javascript objects work then find out if you are right by reading our new take on Javascript OOP - it's not object orientation as we know it but it is another reason why Javascript is such a Jem.

This is the first of a series of articles dealing with the tricky but fascinating story of Javascript and objects.

This isn't the usual story, however, but one that is more suited to the way Javascript works. We start off by looking at why Javascript is different and its most basic method of object creation and take a quick look at how we can work without classes.

In the next and subsequent installments we look at the central role that the function object plays in creating object factories and the more specialised object constructors. Finally we will reach something you might well recognise, but when we do you will see it in a new light and be able to invent new ways of working with objects.

But to start at the beginning...

One of the most misunderstood aspects of JavaScript is its status as an object-oriented language.

Given the range of possible approaches to objects, and the equally wide range of strongly held beliefs about which is the one and only true way you, can tell that it’s a topic that can run and run. However, there are issues that go to the practical use of the language and of these the statement that “JavaScript is a prototype-based” language is perhaps the most important.

Many books perpetuate the myth that this is something mysterious to do with the Prototype property, but in fact the Prototype property is more to do with efficiency than anything else - you could do Javascript OOP without ever needing it.

The biggest problem is that most programmers feel happier with Javascript if it is forced into the straitjacket of classical object-oriented programming. The attempts to cast it as a class-oriented language complete with inheritance and the usual trappings make it difficult to see how it all really works.

So let's start from the beginning and look at what facilities Javascript makes available for object-oriented programming without trying to make it look like something else.

Parts of this story you will almost certainly already know - what matters is the way that they connect together.

Class v Prototypical objects

There are two very general approaches to creating objects in object oriented languages.

You can go about it indirectly and create a “class” from which you instantiate as many objects as you need.

The class acts as a sort of tool that can be used to stamp out copies of the object.

Many beginners find this difficult because they are focused on producing something that “does something” rather than working one stage removed – class then object.

A prototype language, on the other hand, doesn’t bother with classes at all – it’s class free.

What happens is that the programmer creates objects by writing the code that implements a single object.

Beginners tend to like this as it is direct – you want an object so you write the code for the object, no mucking about with classes that simply get in the way and cause problems with thinking up names.

For example, if you need a stack object in a class-based language you first have to implement a class called CStack and then create an instance of a stack object something like:

CStack Stack=new CStack()

In a prototype language you don’t have to invent CStack as a template for the stack object you simply write the code that is within CStack as if it was the Stack object and get on with using it.

This is the approach that JavaScript takes but it isn’t the first language to do so – for example Visual Basic 6 also took the prototype approach to creating forms. In this case you simply coded an object called Form1 and used it. Even VB .NET works in this way see: In Praise of VB.

Of course creating a single instance of an object doesn’t really give you the full benefit of an object-oriented approach but prototype languages solve this by providing the ability to clone objects.

Instead of stamping out identical objects using a class you simply create more objects by cloning existing objects. Once you have the cloned object you can change its behaviour by adding methods and properties to it.

In fact most prototype languages don’t bother providing a facility to create a new object, they simply provide some built-in objects that you can clone to create your own objects.

So to be clear:

• a prototype based language doesn’t have classes
• instead you create objects directly

JavaScript is a prototype-based language… and almost everything is an object.

Creating and using an object

At this point, if you know your Javascript, you are probably expecting an account of using the new operator and functional constructors to generate objects.

This is one way of doing the job but it really isn't Javascript's native way of approaching the task.

In fact using new in conjunction with a constructor function is just one of the possible object factory approaches to OOP in Javascript.

Let's start at the beginning and the most appropriate beginning.

The fundamental Javascript object construction technique is the object literal - usually dismissed as a way of building data structures, or as a vital part of the JSON approach to data exchange. The object literal is not only useful it is the theoretical heart of Javascript's approach to OOP.

You can create an object simply by writing down the properties and methods it should have. The null object, i.e. an object with no properties or methods is simply:

var nullObject={};

The null object is sometimes a useful starting point because we can add properties and methods to it later on. Let's move on to consider an object with a single property and a single method:

var myObject = 
 {
   myProperty:123,
   myMethod:function(){
         return myObject.myProperty;} 
 };

You probably already know the basic syntax. Each property or method is defined as part of a comma separated list as a set of name:value  pairs. So a general object is created using:

var myObject =
 {
   property1:value1,
   property2:value2,
         ...
   propertyN:valueN
 };                            

And we are using the view that a method is simply a property that just happens to have a function as its value.

<ASIN:0596517742>

<ASIN:0321572602>

<ASIN:0470526912>

<ASIN:1590597273>