Professional JavaScript

Implementing JavaScript Inheritance

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.

Understanding 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. Recall Chapter 2 describes 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.