Welcome to Part 8 of this review of the Pluralsight and Front End Masters course Advanced JavaScript by Kyle Simpson.

Kyle Simpson is Head of Curriculum for MakerSquare and an evangelist of the open web. He lives in Austin, Texas, and is passionate about all things JavaScript.

He’s written 8 books published by O’Reilly, including six books in the You Don’t Know JS series.

Kyle teaches JavaScript and has eight courses recorded by Front End Masters.

He’s a public speaker, and contributes to the world of OSS.

In this series:

Part 1 – Introduction
Part 2 – Scope
Part 3 – Lexical Scope
Part 4 – Block scoping
Part 5 – Dynamic Scope, Hoisting and this
Part 6 – Closure
Part 7 – Object Prototypes
Part 8 – Inheritance and OLOO
Part 9 – Async Patterns

Inheritance

Kyle begins by describing classical inheritance, and we hear the word “copy” many times.

One metaphor is the class is the blueprints of a building, and then a builder builds it, copying the characteristics of the blueprints into the physical building.

The mechanism used in JavaScript is often called “prototypal inheritance”to distinguish it from inheritance, but JavaScript doesn’t really use inheritance at all.

JavaScript uses delegation links. We see a diagram with the arrows going in the opposite direction to those of inheritance.

• Inheritance is copy down
• Behavior delegation is a delegation up the chain

We have invented a lot of inheritance workarounds for this such as the mixin pattern which manually copies things from one prototype to another.

Kyle argues that we should use the term “Behavior Delegation” instead of “Prototypal Inheritance”

OLOO: Objects Linked to Other Objects

All we care about in JavaScript is objects and what they are linked to. The rest of this module derives an OLOO coding style.

We begin with an earlier code sample and the aim is to simplify it. We begin by changing one line into two!

var b1 = new Bar(“b1”);

becomes:

var b1 = Object.create(Bar.prototype);
Bar.call(b1,”b1″);

Kyle ask you to bare with him on these intermediate forms. The first thing we’ve achieved is avoiding doing class instantiation anymore.  The next step is to remove all references to .prototype

In the next slide the only remaining .prototype is Foo.prototype.identify

The final step is to remove that and the Foo constructor:

var Foo = {
init: function(who) {
this.me = who;
},
identify: function() {
return “I am ” + this.me;
}
};

var Bar = Object.create(Foo);

Bar.speak = function() {
alert(“Hello, ” + this.identify() + “.”);
};

var b1 = Object.create(Bar);
b1.init(“b1”);
b1.speak(); // alerts: “Hello, I am b1.”

We now have the same functionality but with simpler non class-oriented code.

OLOO Questions

Q. What if you wanted to delegate to more the one object?
A. There’s only one prototype chain.

Q. Bar cannot have an init function?
A. Bar doesn’t have a constructor. It could have an init, and it did on a previous slide, but I moved it all the way up to Foo.

Q. There’s no more constructors?
A. There’s no more constructors.

Q. An object that has all these methods on it and you create lots of those objects, versus using the prototype – doesn’t the prototype perform better?
A. This is the exact same mechanism and functionality and it will have the exact same performance characteristics.

Q. Are there real word examples of this OLOO style?
A. OLOO is something I invented recently so there aren’t a lot of examples. I’m still trying to convince people to stop trying to do classes.

Q. What is the main pushback that you get from proponents of class-oriented JavaScript coding?
A. I recommend reading this & object prototypes book chapters 4, 5 and 6 are all about what we’ve just discussed. The primary pushback is “classes are how we’ve been taught…there are certain problems that require classes”.

In the real world the whole concept of classification is actually somewhat unnatural. The biggest pushback is people don’t want to change their thinking.

Kyle shows a diagram explaining the same code using the OLOO style. It is dramatically simpler than the original design.

Q. Please explain Object.create?
A. It’s the polyfill for object create in pre-ES5:

if (!Object.create) {
Object.create = function (o) {
function F() {}
F.prototype = o;
return new F();
};
}

We’ve got function and prototypes and new constructors. We took this crap out of our code and hid it inside of a nice clean utility.

Gists on the OLOO pattern:

https://gist.github.com/getify/5572383

https://gist.github.com/getify/5226305

Quiz: Prototype

Once again watch the course for the answers

1. How is JavaScript’s [[Prototype]] chain not like traditional/classical inheritance?
2. What does “behavior delegation” mean and how does it describe object linking in JS?
3. Why is “behavior delegation” as a design pattern a helpful thing? What are the tradeoffs?

In this clip Kyle also talks about ES6 classes and how they go “further down the bad path”.

He says 95% of the time when he designs software he uses the module pattern, and the other 5% of the time he uses OLOO style delegation.

Exercise 4

Create a widget and a button as a parent and child class. First use the prototype pattern and model it as a parent-child class thing. Then refactor it to the OLOO style.

Q. Any circumstances for using two design patterns, e.g. use OLOO to delegate a module or vice versa?

A. It doesn’t happen often but I’ve done that before. You have to be careful because delegation can sometimes be counterproductive to the encapsulation that you’re trying to do with modules and vice versa.

Delegation is not a general hammer that you use everywhere.

Continue to the Final Part – Async Patterns