JavaScript is weakest in its object-oriented support when it comes to inheritance. The features are there for you to do it, but unless you're organized, nothing will work as you expect. In order to see the issues, first a bit of theory about objects, classes, and instances.
If you have an object, then usually there are some properties containing data or methods in it. However it is also usually possible to write down some information about that object. At the simplest you can write down its name (from the constructor function perhaps) and the number and type of properties it has. In object-oriented lingo, that kind of information is called an object class definition. A class definition has the same role for an object that a type has for a primitive bit of data such as a number. "Class definition" and "object type" are interchangeable ideas. An actual object itself is called an object instance. Instance just means "one of" that type of object. Therefore it's common to see many object instances for a given object class. Remember how to use a JavaScript object constructor to create as many objects as you like.
There is a general expectation in object-oriented languages that once the details of an object class are settled they won't change. Individual bits of data in an object instance might change, but not the class. This expectation comes from strongly typed languages like C++ and Java. In those languages, it's not a basic process to get at the information in an object class; you have to use an extra-special mechanism (like Run Time Type Information [RTTI] or Reflection) and you certainly can't change an object class once it exists. This is also consistent with the way primitive types work – you can easily change a variable holding a particular value of type Number (say 5) into a different value (say 6), but you can't change the Number type itself (say, by increasing the range of allowed numbers, or by banning negative numbers). If you did that, then maybe you would call the changed type BigPositiveNumber to distinguish it from the normal Number type.
This all helps to understand how objects that inherit information are managed. This diagram illustrates the pieces at work:
Notice how the classes and instances are nicely divided – instances exist (like speech) but classes are more abstract (like thought). In strongly typed languages like C++ and Java the two rarely meet, and classes are never modified.
In JavaScript, the picture is more like this:
In JavaScript, classes are ordinary objects too – created when you make a constructor function. That means you can accidentally damage classes in your program. Or you can deliberately change classes. It also makes it easy to mix up class objects and "ordinary" instance objects. In fact the whole idea of separate, abstract classes breaks down a bit in JavaScript.
Because of this breakdown, it's better to focus on prototypes, which is the mechanism available. However, it pays to understand classes and instances. Both are implemented with the same mechanism (JavaScript Objects) and both are modifiable, so the objects available can become extremely fluid (and unpredictable). Sometimes it pays to be able to think in class/instance terms; but if you're a real computer guru then sometimes you'll want to throw out the class/instance split entirely.
There is one rock to cling to. A JavaScript object doesn't define host objects – they are defined elsewhere. Therefore you can nearly always be sure that host object definitions will never, ever, change.
In the above diagram there are some question marks. In particular, what does the prototype property get set to when you're trying to get rectangles to inherit from polygons? It turns out that there are two main possibilities.
The simplest form of inheritance in JavaScript is for the object instance for the derived class to collect the information it inherits from the class definition object for its base class. Therefore this is a case of mixing up instance and class objects.
function Polygon() {
this.edges = 8; // octogons are the default
this.regular = false; // sides needn't be all the same
this.area = new Function (...) // some hard mathematics
}
function Rectangle(top_len, side_len) {
this.edges = 4;
this.top = top_len;
this.side = side_len;
this.area = new Function("return this.top*this.sides");
}
Rectangle.prototype = new Polygon;
This example has two object constructors: the two functions. Since functions are objects in JavaScript, there are two new objects as well. There is also a third new object. It has been added to the Rectangle function object's prototype chain in the last line, and that is the only place it is accessible. That object can be thought of as a class definition object, because it is only really used at object creation time, and there is only ever one of it.
To create a new Rectangle, use this code:
var box = new Rectangle(8,3);
Afterwards the object's properties are:
box.edges = 4 // overrides Polygon
box.top = 8
box.side = 3
box.area = Function("return this.top*this.sides");
box.regular=false // from Polygon
The benefits of this approach are:
However, this approach does have drawbacks. The problems mostly revolve around the fact that there is only one prototype chain for the Rectangle constructor, and it is shared between all Rectangle objects that are created. So any Rectangle object that modifies properties of the base class changes them for all Rectangle objects.
You can work around the first problem by overriding all the base class objects properties in the derived instance object constructor (Rectangle). However, if you do that, overriding everything, one wonders why bother use inheritance at all – you might as well just have a separate object type.
Sometimes you do want properties in the base class to be updated by every derived instance ('static class variables'). Here's an example:
function Counter() { this.total=0; }
function StockItem() { this.total++; }
StockItem.prototype = new Counter;
var biscuits = new StockItem; // total = 1
var coffee = new StockItem; // total = 2
Every object contributes something to the shared property. In the example above, this property is a total of the objects currently existing (this simple example doesn't correctly decrease the total if objects go away).
Finally, if you can avoid changing any state in the base class object, then the approach we've outlined here can still be quite useful. You could put a store of constant data and methods in it that will be usable by all derived instance objects. The methods in the base class object can refer to properties in derived instances as well. Here's an example:
function Base(v) {
if (arguments.length != 0) this.value = v;
this.double_up = new Function ("this.value*=2;")
}
function Derived(v) {this.value = v;}
Derived.prototype = new Base;
var obj = new Derived(5);
obj.double_up(); // this.value = 10
Notice how in this example the base class object uses, but may never define the value property. In that case, the derived instance object's value property will be doubled. The 'if' condition in the base class object is only true if the Base() function is used as a simple constructor, not when inheritance is at work. For C++ and Java experts: this mechanism works well for abstract base classes.
If you want to create a derived object instance, and you don't want the risk that it might be changed under you, then this is the approach to use. Here is the example from the last section slightly modified:
function Polygon() {
this.edges = 8; // octogons are the default
this.regular = false; // sides needn't be all the same
this.area = new Function (...) // some hard mathematics
}
function Rectangle(top_len,side_len) {
this.temp = Polygon;
this.temp();
delete this.temp; // or this.temp = null;
this.edges = 4;
this.top = top_len;
this.side = side_len;
this.area = new Function("return this.top*this.sides");
}
In addition to three new lines, the prototype assignment line at the end is missing as well. There are no prototype chains in this example at all. Instead, when the object is constructed, a temporary property is made for the base class' constructor, and that constructor is called as though it were a method of that object. All the properties set by the Polygon constructor are set directly in the Rectangle object. This has to be done first in the Rectangle constructor, because if it were last, some of the properties set by the derived object might be overridden by the base class constructor – back to front. In fact, when the base class constructor is called, it thinks that it is operating on an object whose destiny is to be of that base class type.
When the temp() method is called in the above example, you can supply arguments to it much like any method – of course those arguments should make sense when the Polygon() constructor gets them.
'ECMAScript 2' plans to replace this awkward three-statement approach with new, purpose-built functions requiring only a single statement:
this.call(Polygon, argument1, argument2, …)
or
this.apply(Polygon, array-of-arguments)
According to the draft of 'ECMAScript 2', the two functions differ only in how arguments are supplied to them. At the time of writing, these functions are too new to be relied upon much. Nevertheless, you can find them in Netscape browsers, versions 4.06 and greater and Internet Explorer 5.0, or where JScript 5.0 is installed.
The benefits of this second inheritance approach, regardless of what syntax you use are:
The drawbacks of this approach are:
If this line is added back at the very end, then the deeper-level inheritance problems go away.
Rectangle.prototype = new Polygon;
However, since all type properties of the base class were set directly into the derived class, all of the base class properties are now overridden – changes to the base class won't necessarily filter through to the derived class. So it is a mistake to think that doing this gives you all the benefits that were to be had in the first approach to inheritance.
Finally, this system supports multiple inheritance. The multiple inheritance it supports is only one level deep, however. All that is required is to repeat the trick at the core of this technique more than once:
...
function Rectangle(top_len,side_len) {
this.temp = Base1; // first base class as before
this.temp();
delete this.temp;
this.temp = Base2; // second base class, similarly
this.temp();
delete this.temp;
...
}
These references are invaluable sources of information on prototype inheritance if you want to get your hands really dirty.
At Sun Microsystems, http://www.sunlabs.com/research/self/papers/papers.html contains a number of articles about the Self language. Self may be considered the precursor to the JavaScript language in many respects.