In this book, JavaScript’s style of object-oriented programming (OOP) is introduced in four steps. This chapter covers steps 2–4, 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.
  

Prototypes are JavaScript’s only inheritance mechanism: Each object has a prototype that is either 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:

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 = {
};
  __proto__: proto,
};

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', 'protoProp']);
// The inherited property itself is unchanged:

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:

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 proto2 = {};
const obj = Object.create(proto1);
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 o = {__proto__: p};
assert.equal(p.isPrototypeOf(o), true);
// (more on that later)

26.1.3. Sharing data via prototypes

Consider the following code:

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

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 = {
    return 'Person named ' + this.name;
};
  __proto__: PersonProto,
};
  __proto__: PersonProto,
};

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

The diagram in fig. 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');

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:

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

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

assert.equal(jane.describe(), 'Person named Jane');
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:

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 (, 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

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:

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:

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

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 {
    this.prop = prop;
  protoMethod() {
  }
    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:

> foo.prop
'protoMethod'
'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.

  static staticMethod() {
  }
    return 'staticGetter';
}

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

'staticMethod'
'staticGetter'

26.2.6. The instanceof operator

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

true
false
true
true

We’ll explore the instanceof operator in more detail , 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.

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 {
    this._counter = counter;
  }
    if (this._counter < 1) return;
    if (this._counter === 0) {
    }
}
// The two properties aren’t really private:
  Reflect.ownKeys(new Countdown()),

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 . This is a preview:

let _counter = new WeakMap();
  constructor(counter, action) {
    _action.set(this, action);
  dec() {
    if (counter < 1) return;
    _counter.set(this, counter);
      _action.get(this)();
  }
assert.deepEqual(
  []);

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 for details.

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

class Person {
    this.name = name;
  describe() {
  }
    for (const person of persons) {
    }
}
  constructor(name, title) {
    this.title = title;
  describe() {
      ` (${this.title})`;
}
const jane = new Employee('Jane', 'CTO');
  jane.describe(),

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

26.4.1. Subclasses under the hood (advanced)

The classes Person and Employee from the previous section are made up of several objects (fig. ). 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:

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

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

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

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.

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:

true
true

Fig. 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:

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?

true
true
true

This prototype chain (visualized in fig. ) 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:

true
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
> (() => {}) instanceof Object
> /abc/ug instanceof Object

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

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

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

> Object.prototype instanceof Object

26.4.4. Dispatched vs. direct method calls (advanced)

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

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

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:

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:

> obj.hasOwnProperty('foo')
> obj.hasOwnProperty('bar')

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

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

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

false
true

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

false
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:

  setBrand(brand) {
    return this;
  getBrand() {
  }

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

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

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

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.

  ···