Please support this book: buy it or donate

26. Prototype chains and classes

In this book, JavaScript’s style of object-oriented programming (OOP) is introduced in four steps. This chapter covers steps 2–4, the previous chapter covers step 1. The steps are (fig. 8):

• Single objects: How do objects, JavaScript’s basic OOP building blocks, work in isolation?
• Prototype chains: Each object has a chain of zero or more prototype objects. Prototypes are JavaScript’s core inheritance mechanism.
• Classes: JavaScript’s classes are factories for objects. The relationship between a class and its instances is based on prototypal inheritance.
• Subclassing: The relationship between a subclass and its superclass is also based on prototypal inheritance.
  

26.1. Prototype chains

Prototypes are JavaScript’s only inheritance mechanism: Each object has a prototype that is either null or an object. In the latter case, the object inherits all of the prototype’s properties.

In an object literal, you can set the prototype via the special property proto:

const proto = {
  protoProp: 'a',
};
const obj = {
  __proto__: proto,
  objProp: 'b',
};
// obj inherits .protoProp:
assert.equal(obj.protoProp, 'a');
assert.equal('protoProp' in obj, true);

Given that a prototype object can have a prototype itself, we get a chain of objects – the so-called prototype chain. That means that inheritance gives us the impression that we are dealing with single objects, but we are actually dealing with chains of objects.

Fig. 9 shows what the prototype chain of obj looks like.

Non-inherited properties are called own properties. obj has one own property, .objProp.

26.1.1. Pitfall: only first member of prototype chain is mutated

One aspect of prototype chains that may be counter-intuitive is that setting any property via an object – even an inherited one – only changes that object – never one of the prototypes.

Consider the following object obj:

const proto = {
  protoProp: 'a',
};
const obj = {
  __proto__: proto,
  objProp: 'b',
};

When we set the inherited property obj.protoProp in line A, we “change” it by creating an own property: When reading obj.protoProp, the own property is found first and its value overrides the value of the inherited property.

assert.deepEqual(Object.keys(obj), ['objProp']);
obj.protoProp = 'x'; // (A)
// We created a new own property:
assert.deepEqual(Object.keys(obj), ['objProp', 'protoProp']);
// The inherited property itself is unchanged:
assert.equal(proto.protoProp, 'a');

The prototype chain of obj is depicted in fig. 10.

26.1.2. Tips for working with prototypes (advanced)

26.1.2.1. Avoid proto (except in object literals)

I recommend to avoid the special property proto: It is implemented via a getter and a setter in Object.prototype and therefore only available if Object.prototype is in the prototype chain of an object. That is usually the case, but to be safe, you can use these alternatives:

• The best way to set a prototype is when creating an object. E.g. via:

Object.create(proto: Object) : Object

If you have to, you can use Object.setPrototypeOf() to change the prototype of an existing object.

• The best way to get a prototype is via the following method:

Object.getPrototypeOf(obj: Object) : Object

This is how these features are used:

const proto1 = {};
const proto2 = {};
const obj = Object.create(proto1);
assert.equal(Object.getPrototypeOf(obj), proto1);
Object.setPrototypeOf(obj, proto2);
assert.equal(Object.getPrototypeOf(obj), proto2);

Note that proto in object literals is different. There, it is a built-in feature and always safe to use.

26.1.2.2. Check: is an object a prototype of another one?

A looser definition of “o is a prototype of p” is “o is in the prototype chain of p”. This relationship can be checked via:

p.isPrototypeOf(o)

For example:

const p = {};
const o = {__proto__: p};
assert.equal(p.isPrototypeOf(o), true);
assert.equal(o.isPrototypeOf(p), false);
// Object.prototype is almost always in the prototype chain
// (more on that later)
assert.equal(Object.prototype.isPrototypeOf(p), true);

26.1.3. Sharing data via prototypes

Consider the following code:

const jane = {
  name: 'Jane',
  describe() {
    return 'Person named '+this.name;
  },
};
const tarzan = {
  name: 'Tarzan',
  describe() {
    return 'Person named '+this.name;
  },
};
assert.equal(jane.describe(), 'Person named Jane');
assert.equal(tarzan.describe(), 'Person named Tarzan');

We have two objects that are very similar. Both have two properties whose names are .name and .describe. Additionally, method .describe() is the same. How can we avoid that method being duplicated?

We can move it to a shared prototype, PersonProto:

const PersonProto = {
  describe() {
    return 'Person named ' + this.name;
  },
};
const jane = {
  __proto__: PersonProto,
  name: 'Jane',
};
const tarzan = {
  __proto__: PersonProto,
  name: 'Tarzan',
};

The name of the prototype reflects that both jane and tarzan are persons.

The diagram in fig. 11 illustrates how the three objects are connected: The objects at the bottom now contain the properties that are specific to jane and tarzan. The object at the top contains the properties that is shared between them.

When you make the method call jane.describe(), this points to the receiver of that method call, jane (in the bottom left corner of the diagram). That’s why the method still works. The analogous thing happens when you call tarzan.describe().

assert.equal(jane.describe(), 'Person named Jane');
assert.equal(tarzan.describe(), 'Person named Tarzan');

26.2. Classes

We are now ready to take on classes, which are basically a compact syntax for setting up prototype chains. While their foundations may be unconventional, working with JavaScript’s classes should still feel familiar – if you have used an object-oriented language before.

26.2.1. A class for persons

We have previously worked with jane and tarzan, single objects representing persons. Let’s use a class to implement a factory for persons:

class Person {
  constructor(name) {
    this.name = name;
  }
  describe() {
    return 'Person named '+this.name;
  }
}

jane and tarzan can now be created via new Person():

const jane = new Person('Jane');
assert.equal(jane.describe(), 'Person named Jane');
const tarzan = new Person('Tarzan');
assert.equal(tarzan.describe(), 'Person named Tarzan');

26.2.2. Class expressions

The previous class definition was a class declaration. There are also anonymous class expressions:

const Person = class { ··· };

And named class expressions:

const Person = class MyClass { ··· };

26.2.3. Classes under the hood (advanced)

There is a lot going on under the hood of classes. Let’s look at the diagram for jane (fig. 12).

The main purpose of class Person is to set up the prototype chain on the right (jane, followed by Person.prototype). It is interesting to note that both constructs inside class Person (.constructor and .describe()) created properties for Person.prototype, not for Person.

The reason for this slightly odd approach is backward compatibility: Prior to classes, constructor functions (ordinary functions, invoked via the new operator) were often used as factories for objects. Classes are mostly better syntax for constructor functions and therefore remain compatible with old code. That explains why classes are functions:

> typeof Person
'function'

In this book, I use the terms constructor (function) and class interchangeably.

Many people confuse .proto and .prototype. Hopefully, the diagram in fig. 12 makes it clear, how they differ:

• .proto is a special property for accessing the prototype of an object.
• .prototype is a normal property that is only special due to how the new operator uses it. The name is not ideal: Person.prototype does not point to the prototype of Person, it points to the prototype of all instances of Person.

26.2.3.1. Person.prototype.constructor

There is one detail in fig. 12 that we haven’t looked at, yet: Person.prototype.constructor points back to Person:

> Person.prototype.constructor === Person
true

This setup is also there for historical reasons. But it also has two benefits.

First, each instance of a class inherits property .constructor. Therefore, given an instance, you can make “similar” objects via it:

const jane = new Person('Jane');
const cheeta = new jane.constructor('Cheeta');
// cheeta is also an instance of Person
// (the instanceof operator is explained later)
assert.equal(cheeta instanceof Person, true);

Second, you can get the name of the class that created a given instance:

const tarzan = new Person('Tarzan');
assert.equal(tarzan.constructor.name, 'Person');

26.2.4. Class definitions: prototype properties

The following code demonstrates all parts of a class definition Foo that create properties of Foo.prototype:

class Foo {
  constructor(prop) {
    this.prop = prop;
  }
  protoMethod() {
    return 'protoMethod';
  }
  get protoGetter() {
    return 'protoGetter';
  }
}

Let’s examine them in order:

• .constructor() is called after creating a new instance of Foo, to set up that instance.
• .protoMethod() is a normal method. It is stored in Foo.prototype.
• .protoGetter is a getter that is stored in Foo.prototype.
  The following interaction uses class Foo:

> const foo = new Foo(123);
> foo.prop
123
> foo.protoMethod()
'protoMethod'
> foo.protoGetter
'protoGetter'

26.2.5. Class definitions: static properties

The following code demonstrates all parts of a class definition that create so-called static properties – properties of the class itself.

class Bar {
  static staticMethod() {
    return 'staticMethod';
  }
  static get staticGetter() {
    return 'staticGetter';
  }
}

The static method and the static getter are used as follows.

> Bar.staticMethod()
'staticMethod'
> Bar.staticGetter
'staticGetter'

26.2.6. The instanceof operator

The instanceof operator tells you if a value is an instance of a given class:

> new Person('Jane') instanceof Person
true
> ({}) instanceof Person
false
> ({}) instanceof Object
true
> [] instanceof Array
true

We’ll explore the instanceof operator in more detail later, after we have looked at subclassing.

26.2.7. Why I recommend classes

I recommend using classes for the following reasons:

• Classes are a common standard for object creation and inheritance that is now widely supported across frameworks (React, Angular, Ember, etc.).
• They help tools such as IDEs and type checkers with their work and enable new features.
• They are a foundation for future features such as value objects, immutable objects, decorators, etc.
• They make it easier for newcomers to get started with JavaScript.

• JavaScript engines optimize them. That is, code that uses classes is usually faster than code that uses a custom inheritance library.
  That doesn’t mean that classes are perfect. One issue I have with them, is:

• Classes look different from what they are under the hood. In other words, there is a disconnect between syntax and semantics.
  It would be nice if classes were (syntax for) constructor objects (new-able prototype objects) and not to constructor functions. But backward compatibility is a legitimate reason for them being the latter.

26.3. Private data for classes

This section describes techniques for hiding some of the data of an object from the outside. We discuss them in the context of classes, but they also work for objects created directly, via object literals etc.

26.3.1. Private data: naming convention

The first technique makes a property private by prefixing its name with an underscore. This doesn’t protect the property in any way; it merely signals to the outside: “You don’t need to know about this property.”

In the following code, the properties ._counter and ._action are private.

class Countdown {
  constructor(counter, action) {
    this._counter = counter;
    this._action = action;
  }
  dec() {
    if (this._counter < 1) return;
    this._counter--;
    if (this._counter === 0) {
      this._action();
    }
  }
}
// The two properties aren’t really private:
assert.deepEqual(
  Reflect.ownKeys(new Countdown()),
  ['_counter', '_action']);

With this technique, you don’t get any protection and private names can clash. On the plus side, it is easy to use.

26.3.2. Private data: WeakMaps

Another technique is to use WeakMaps. How exactly that works is explained in the chapter on WeakMaps. This is a preview:

let _counter = new WeakMap();
let _action = new WeakMap();
class Countdown {
  constructor(counter, action) {
    _counter.set(this, counter);
    _action.set(this, action);
  }
  dec() {
    let counter = _counter.get(this);
    if (counter < 1) return;
    counter--;
    _counter.set(this, counter);
    if (counter === 0) {
      _action.get(this)();
    }
  }
}
// The two pseudo-properties are truly private:
assert.deepEqual(
  Reflect.ownKeys(new Countdown()),
  []);

This technique offers you considerable protection from outside access and there can’t be any name clashes. But it is also more complicated to use.

26.3.3. More techniques for private data

There are more techniques for private data for classes. These are explained in “Exploring ES6”.

The reason why this section does not go into much depth, is that JavaScript will probably soon have built-in support for private data. Consult the ECMAScript proposal “Class Public Instance Fields & Private Instance Fields” for details.

26.4. Subclassing

Classes can also subclass (“extend”) existing classes. As an example, the following class Employee subclasses Person:

class Person {
  constructor(name) {
    this.name = name;
  }
  describe() {
    return `Person named ${this.name}`;
  }
  static logNames(persons) {
    for (const person of persons) {
      console.log(person.name);
    }
  }
}
class Employee extends Person {
  constructor(name, title) {
    super(name);
    this.title = title;
  }
  describe() {
    return super.describe() +
      ` (${this.title})`;
  }
}
const jane = new Employee('Jane', 'CTO');
assert.equal(
  jane.describe(),
  'Person named Jane (CTO)');

Two comments:

• Inside a .constructor() method, you must call the super-constructor via super(), before you can access this. That’s because this doesn’t exist before the super-constructor was called (this phenomenon is specific to classes).

• Static methods are also inherited. For example, Employee inherits the static method .logNames():

> 'logNames' in Employee
true

26.4.1. Subclasses under the hood (advanced)

The classes Person and Employee from the previous section are made up of several objects (fig. 13). One key insight for understanding how these objects are related, is that there are two prototype chains:

• The instance prototype chain, on the right.
• The class prototype chain, on the left.

26.4.1.1. The instance prototype chain (right column)

The instance prototype chain starts with jane and continues with Employee.prototype and Person.prototype. In principle, the prototype chain ends at this point, but we get one more object: Object.prototype. This prototype provides services to virtually all objects, which is why it is included here, too:

> Object.getPrototypeOf(Person.prototype) === Object.prototype
true

26.4.1.2. The class prototype chain (left column)

In the class prototype chain, Employee comes first, Person next. Afterwards, the chain continues with Function.prototype, which is only there, because Person is a function and functions need the services of Function.prototype.

> Object.getPrototypeOf(Person) === Function.prototype
true

26.4.2. instanceof in more detail (advanced)

We have not yet seen how instanceof really works. Given the expression x instanceof C, how does instanceof determine if x is an instance of C? It does so by checking if C.prototype is in the prototype chain of x. That is, the following two expressions are equivalent:

x instanceof C
C.prototype.isPrototypeOf(x)

If we go back to fig. 13, we can confirm that the prototype chain does lead us to the following answers:

> jane instanceof Employee
true
> jane instanceof Person
true
> jane instanceof Object
true

26.4.3. Prototype chains of built-in objects (advanced)

Next, we’ll use our knowledge of subclassing to understand the prototype chains of a few built-in objects. The following tool function p() helps us with our explorations.

const p = Object.getPrototypeOf.bind(Object);

We extracted method .getPrototypeOf() of Object and assigned it to p.

26.4.3.1. The prototype chain of {}

Let’s start by examining plain objects:

> p({}) === Object.prototype
true
> p(p({})) === null
true

Fig. 14 shows a diagram for this prototype chain. We can see that {} really is an instance of Object – Object.prototype is in its prototype chain.

Object.prototype is a curious value: It is an object, but it is not an instance of Object:

> typeof Object.prototype
'object'
> Object.prototype instanceof Object
false

That can’t be avoided, because Object.prototype can’t be in its own prototype chain.

26.4.3.2. The prototype chain of []

What does the prototype chain of an Array look like?

> p([]) === Array.prototype
true
> p(p([])) === Object.prototype
true
> p(p(p([]))) === null
true

This prototype chain (visualized in fig. 15) tells us that an Array object is an instance of Array, which is a subclass of Object.

26.4.3.3. The prototype chain of function () {}

Lastly, the prototype chain of an ordinary function tells us that all functions are objects:

> p(function () {}) === Function.prototype
true
> p(p(function () {})) === Object.prototype
true

26.4.3.4. Objects that aren’t instances of Object

An object is only an instance of Object if Object.prototype is in its prototype chain. Most objects created via various literals are instances of Object:

> ({}) instanceof Object
true
> (() => {}) instanceof Object
true
> /abc/ug instanceof Object
true

Objects that don’t have prototypes are not instances of Object:

> ({ __proto__: null }) instanceof Object
false
> Object.create(null) instanceof Object
false

Object.prototype ends most prototype chains. Its prototype is null, which means it isn’t an instance of Object, either:

> Object.prototype instanceof Object
false

26.4.4. Dispatched vs. direct method calls (advanced)

Let’s examine how method calls work with classes. We revisit jane from earlier:

class Person {
  constructor(name) {
    this.name = name;
  }
  describe() {
    return 'Person named '+this.name;
  }
}
const jane = new Person('Jane');

Fig. 16 has a diagram with jane’s prototype chain.

Normal method calls are dispatched. To make the method call jane.describe():

• JavaScript first looks for the value of jane.describe, by traversing the prototype chain.
• Then it calls the function it found, while setting this to jane. this is the receiver of the method call (where the search for property .describe started).
  This way of dynamically looking for methods, is called dynamic dispatch.

You can make the same method call while bypassing dispatch:

Person.prototype.describe.call(jane)

This time, Person.prototype.describe is an own property and there is no need to search the prototypes. We also specify this ourselves, via .call().

Note how this always points to the beginning of a prototype chain. That enables .describe() to access .name. And it is where the mutations happen (should a method want to set the .name).

26.4.4.1. Borrowing methods

Direct method calls become useful when you are working with methods of Object.prototype. For example, Object.prototype.hasOwnProperty() checks if an object has a non-inherited property whose key is as given:

> const obj = { foo: 123 };
> obj.hasOwnProperty('foo')
true
> obj.hasOwnProperty('bar')
false

However, this method may be overridden. Then a dispatched method call doesn’t work:

> const obj = { hasOwnProperty: true };
> obj.hasOwnProperty('bar')
TypeError: obj.hasOwnProperty is not a function

The work-around is to use a direct method call:

> Object.prototype.hasOwnProperty.call(obj, 'bar')
false
> Object.prototype.hasOwnProperty.call(obj, 'hasOwnProperty')
true

This kind of direct method call is often abbreviated as follows:

> ({}).hasOwnProperty.call(obj, 'bar')
false
> ({}).hasOwnProperty.call(obj, 'hasOwnProperty')
true

JavaScript engines optimize this pattern, so that performance should not be an issue.

26.4.5. Mixin classes (advanced)

JavaScript’s class system only supports single inheritance. That is, each class can have at most one superclass. A way around this limitation is via a technique called mixin classes (short: mixins).

The idea is as follows: Let’s assume there is a class C that extends a class S – its superclass. Mixins are class fragments that are inserted between C and S.

In JavaScript, you can implement a mixin Mix via a function whose input is a class and whose output is the mixin class fragment – a new class that extends the input. To use Mix(), you create C as follows.

class C extends Mix(S) {
  ···
}

Let’s look at an example:

const Branded = S => class extends S {
  setBrand(brand) {
    this._brand = brand;
    return this;
  }
  getBrand() {
    return this._brand;
  }
};

We use this mixin to insert a class between Car and Object:

class Car extends Branded(Object) {
  constructor(model) {
    super();
    this._model = model;
  }
  toString() {
    return `${this.getBrand()} ${this._model}`;
  }
}

The following code confirms that the mixin worked: Car has method .setBrand() of Branded.

const modelT = new Car('Model T').setBrand('Ford');
assert.equal(modelT.toString(), 'Ford Model T');

Mixins are more flexible than normal classes:

• First, you can use the same mixin multiple times, in multiple classes.

• Second, you can use multiple mixins at the same time. As an example, consider an additional mixin called Stringifiable that helps with implementing .toString(). We could use both Branded and Stringifiable as follows:

class Car extends Stringifiable(Branded(Object)) {
  ···
}